public inbox for
 help / color / mirror / Atom feed
From: Howard Chu <>
To: Christian Tramnitz <>,
Subject: Re: ld: document static libraries when performing static linking
Date: Wed, 21 Feb 2024 20:55:56 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Christian Tramnitz wrote:
> Hello,

Hi -
   a linker plugin to handle static library dependencies already exists, it's
been around nearly 4 years.

There was a bit of a push to make it an integral feature of ld instead of a plugin, but that
has stalled.

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. 
  Director, Highland Sun
  Chief Architect, OpenLDAP

  reply	other threads:[~2024-02-21 20:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2024-02-21 18:01 ` Christian Tramnitz
2024-02-21 20:55   ` Howard Chu [this message]
2024-02-22  3:49     ` Howard Chu
2024-02-28 14:02   ` Nick Clifton
2024-02-28 23:50     ` Christian Tramnitz
2024-02-29 10:58       ` Nick Clifton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).