ld: document static libraries when performing static linking

[Howard Chu]

Christian Tramnitz wrote:
> Hello,

Hi -
   a linker plugin to handle static library dependencies already exists, it's
been around nearly 4 years. https://sourceware.org/pipermail/binutils/2020-September/113188.html

There was a bit of a push to make it an integral feature of ld instead of a plugin, but that
has stalled. https://sourceware.org/pipermail/binutils/2023-February/126155.html

I guess it's worth asking again, what help is needed to move integration forward?

> 
> For statically linked binaries one wants to keep track of external
> libraries that were pulled in at link time. I haven't found any
> initiatives or standards trying to achieve this yet, so I would like
> to make a proposal.
> 
> ld already supports the `--depedency-file=` option to create a
> depfile, to some degree, documenting dependencies in Makefile format.
> While it's a good starting point, it's not sufficient.
> 
> Would it be feasible to create another option, that
> a) just records dependencies to external, static-libs (within the
> depfile this could be achieved by looking for path names outside the
> build dir and having an .a file extension - but this is not
> neccessarily exhaustive). This doesn't need to be unique,
> post-processing is expected to take place anyway.
> b) documents the actual objects (enhanced: down to function level if
> information exists from compiling with -ffunction-sections and
> -fdata-sections) that were pulled in from the library archive, similar
> to the output from `--verbose`
> "(/usr/lib/gcc/x86_64-pc-linux
> -gnu/13/../../../../lib64/libc.a)stpcpy-avx2.o"
> c) outputs this in some sort of structured format for later
> processing, e.g. as simple as
> <object-requiring-the-library>,</some/library.a>,<requested-object-in-library>
> my-obj,/usr/lib64/libc.a,stpcpy-avx2.o
> my-obj,/usr/lib64/libc.a,stpcpy-avx2-rtm.o
> my-obj,/usr/lib64/libc.a,getsrvbynm.o
> my-obj,/usr/lib64/libc.a,stpcpy-evex.o
> d) - if ld doesn't support this already (couldn't find looking through
> man) - ld had some sort of no-op/pretend option that doesn't actually
> produce a linked output but only pretends it would?
> 
> 
> Purpose:
> The consumer of this information might be a distributor, keeping track
> of things in the distribution specific packaging database format. Or
> it could even be embedded into the resulting binary itself.
> 
> 
> Background:
> This output can be used to
> I) validate license compliance (it would make it possible to discover
> conflicting licenses of derived work)
> II) allow vulnerability tracking, when vulnerabilities existed in
> included static libraries (at build/link time)
> 
> The latter would be further supported by b) as a vulnerability may not
> even exist in the resulting object if the vulnerable function wasn't
> included by linking.
> 
> 
> 
> Best regards,
> Christian
> 


-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/