[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[patch #9687] bugfix: make -export-dynamic imply --whole-archive

From: David Lamparter
Subject: [patch #9687] bugfix: make -export-dynamic imply --whole-archive
Date: Sat, 20 Nov 2021 11:28:29 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0

Follow-up Comment #2, patch #9687 (project libtool):

Well, it's now 3 years later, and my memory of details on this is pretty much
gone, but let's try.  No warranty on anything here, I'm trying to

[comment #1 comment #1:]
> Could you maybe elaborate on your use case? Perhaps there's something that
I'm missing.

Any executable linked with `-export-dynamic` that links static libraries may
end up missing globally visible symbols if they are not used by the executable
itself.  If the program then tries to load a module that needs these symbols,
it fails.

> In my opinion : the existing behavior both by `ld' and `libtool' is
appropriate. Implying `--whole-archive' for dependency libraries in with
`-export-dynamic' will prevent users from intentionally localizing symbols.

`--whole-archive` has no impact on symbol visibility; I don't follow at all
what you're trying to say here.  A binary linked with `-export-dynamic` is
essentially a shared library, and the `ld` docs state:

"This is normally used to turn an archive file into a shared library, forcing
every object to be included in the resulting shared library."

I agree `ld` is doing the appropriate thing here, but `libtool` isn't.  A
binary with `-export-dynamic` needs to export ALL of its global symbols from
ALL of its files for dynamically loaded modules to use.  It is essentially a
shared library at the same time and needs to be treated as such.

NB: `--whole-archive` does NOT make all symbols globally visible! This is
about *objects*, i.e. files.  If you have a file getting linked in that has
some global symbols, but none of them are used in the binary itself - `ld`
will drop the entire file.  That's the wrong thing to do for both creating a
shared library as well as for creating an executable with `-export-dynamic`.

> I see these flags as having distinct use cases. I'll note that, the need for
using `--whole-archive' with `ld' isn't necessarily intuitive to users, so I
see the appeal of using it in many situations - but adding additional variance
between `libtool' and `ld' does not seem justified to me.

If I remember correctly, I couldn't find a way to manually add
`--whole-archive` to the linker invocation that libtool does, because the
option is ordering-sensitive to the file names on the ld command line.  I also
do not understand what you mean with "variance" between `libtool` and `ld` -
there is no equivalency here.  `libtool` is a user/wrapper of `ld` that has
the express purpose of figuring out the "right" flags for `ld`, and it's
failing at its job.

Also: what is that distinct use case for `--whole-archive`?  I think it's
exactly this situation right here... the ld docs even hint at it.

> If the intention is to export symbols which are defined in statically linked
`libtool' libraries a "convenience library" ( `noinst_' ) might be what you're
actually looking for?

Barring my memory failing me, I think we tried that and it simply has the same

The patch posted here has been shipped in FRRouting for 3 years now, it has
not caused any breakage in any OS/distribution (prominently: Debian, Ubuntu,
RHEL, *BSD, …) - as such I would urge you to just merge it and move on.  I
would happily help you in understanding the issue here, but I can't do that
with having more or less lost my own understanding of it.  Sorry about that,
but there's a boatload of other stuff I need to understand, and my brain is
not infinite :(.


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]