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/