[prev in list] [next in list] [prev in thread] [next in thread] 

List:       binutils
Subject:    Re: ld: document static libraries when performing static linking
From:       Nick Clifton <nickc () redhat ! com>
Date:       2024-02-28 14:02:37
Message-ID: 57185ecb-ce34-42d0-9023-6af36d49b697 () redhat ! com
[Download RAW message or body]

Hi Christian,

> 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.

If post-processing is an option, then how about using the linker map
file and parsing that ?  Ie link with -Map=foo.map and then post-link
scan foo.map.  That would give you full details of which libraries were
used, and which components from inside those libraries if they are
archives.

It might take a bit of work to get a reasonably robust scanner, but
it would mean that it would work with any version of the linker, and
you would not have the hassle of maintaining a linker plugin.


> 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`

The linker map idea above should let you do this.


> 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

If you do not like the map idea then maybe adding some code to the linker
at the places where it generates its map output, but this time in a format
you like, would work ?


> 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?

It doesn't.  Although of course you can always throw away any files it
creates and start again.


> 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.
There is another possibility...

Check out the annobin project: https://sourceware.org/annobin/

The compiler plugins that are part of this project record notes that
include the filename associated with each compilation unit.  These
notes are aggregated together during a link and end up in the resulting
binary.  So you could scan the binary for these notes, extract the
filenames and you would end up with a list of (main) sources for the
program.  If your static libraries are also compiled with annobin enabled
then they will contain notes of their own that will also contribute to
the final binary.

Cheers
   Nick

[prev in list] [next in list] [prev in thread] [next in thread]