Guidance on supporting static libraries

No files, tests, or entry points are named. Start by reading the existing package-note handling for ELF binaries, shared libraries, and dlopen stanzas, then investigate how static archives and LTO affect metadata propagation. Done requires a resolved design for static-library support and the package-note schema, with concrete validation criteria.

many language ecosystems have great support for documenting and tracing static library linking.
For example in go go version -m /path/to/dir/or/binary prints all go packages that were statically linked.
Similarly when rust binaries are built using cargo-auditable, they can report all the crates they were built with.

I am only just exploring package notes, and it works really well for ELF binaries and shared libraries, and the dlopen stanzas.

I really really want this to work for statically linked libraries too, and for it to work with lto.

Static libraries is just an archive of object files. Thus one cannot really attach the package note to it. One can append an object into the library that just have the package note. And I hope that will be still propagate to a statically linked binary. Alternative to just a single object with a package note.... maybe we should be attaching package note to every .o object, and then deduplicating that information at link time? Or something else?

More fun stuff, making static .a library can be replaced by a linker script that specifies the package.note flags and the underlying static library? :-)

Also not sure about the package note spec. For example, if we need to extend the schema; allow multiple sections; or simply rely on the fact that json allows streams of objects one after another.

Because I really want to expose the information w.r.t. statically linked libraries/packages in the binaries.