public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* ld: document static libraries when performing static linking
@ 2024-02-21 17:28 Christian Tramnitz
  2024-02-21 17:48 ` Jonathan Wakely
  0 siblings, 1 reply; 2+ messages in thread
From: Christian Tramnitz @ 2024-02-21 17:28 UTC (permalink / raw)
  To: gcc

Hello,

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: ld: document static libraries when performing static linking
  2024-02-21 17:28 ld: document static libraries when performing static linking Christian Tramnitz
@ 2024-02-21 17:48 ` Jonathan Wakely
  0 siblings, 0 replies; 2+ messages in thread
From: Jonathan Wakely @ 2024-02-21 17:48 UTC (permalink / raw)
  To: Christian Tramnitz; +Cc: gcc

On Wed, 21 Feb 2024 at 17:29, Christian Tramnitz via Gcc
<gcc@gcc.gnu.org> wrote:
>
> Hello,
>
> 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.

The linker is part of Binutils not GCC:
https://www.gnu.org/software/binutils/

You probably want to use the binutils mailing list, not the GCC one.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-02-21 17:49 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-21 17:28 ld: document static libraries when performing static linking Christian Tramnitz
2024-02-21 17:48 ` Jonathan Wakely

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).