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
reconstruct.
[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
problem.
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:
<https://savannah.gnu.org/patch/?9687>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/