[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:       Christian Tramnitz <christian+gcc-gnu () tramnitz ! com>
Date:       2024-02-28 23:50:03
Message-ID: CADddEsDSmF7kaHXL-XKzjUcJNCaEKb1xckZ1w2v0D2Z3iL-+fA () mail ! gmail ! com
[Download RAW message or body]

Hi Nick,

thanks for your detailed response!

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

-Map does indeed provide the required information - thanks a lot for
the hint, that is already much better than parsing through verbose
build logs or the dependency-file.
However, like --depedency-file, it has one major drawback: when
multiple targets exist, the "last" action overwrites the output file.
I haven't seen an option to use a dynamic file names (foo-$$.map
doesn't seem to work).

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

I indeed looked into annobin initially, but did not get that the notes
also contain references to the sources/archive/library (only compile
options as per https://sourceware.org/annobin/annobin.html/Plugins.html).
But since you're the author, you know better for sure. Will have a
look again as it may cover large parts of what I'm trying to achieve
already. Except for the lookup which package owns that file of course.
But that could be a post-processing step again.


Best regards,
   Christian
[prev in list] [next in list] [prev in thread] [next in thread]