On 2020-09-25, Oleg Smolsky <osmol...@netskope.com> wrote: > On Fri, Sep 25, 2020 at 6:58 AM Bob Friesenhahn > <bfrie...@simple.dallas.tx.us> wrote: > > Libtool convenience libraries are not "real" static libraries. > > Instead they are object files stored in an archive file. Prior to > > use (when linking using libtool) the objects are extracted and > > passed to the linker directly (perhaps with renaming to assure > > there are no over-writes during the extraction). > > Well, AFAIK any well-formed .a file (an archive) is a static lib. And these > can be passed to the linker. Are you saying that libtool extracts the > individual .o files instead passing -lfoo (for libfoo.a)?
Yes, this is how libtool _convenience_ libraries work (at least conceptually: I think in some cases libtool is able to use linker options like -Wl,--whole-archive, if supported, to achieve equivalent results without literally unpacking the archive). This is because _convenience_ libraries are a shorthand for linking the individual libtool objects that comprise the library. Linking an archive is very different from linking the individual objects that make up the archive. Regular (installed) libtool libraries work differently (they are linked like normal libraries). [...] > > The convenience library does not do anything regarding mutiply-defined > > symbols (at the C language level) while linking. If there is a > > conflict then the linker should normally fail. > > I find the situation puzzling. My project has just over a hundred of these > LT convenience libraries and there are several places where collisions > result in renaming. Yet nowhere do I see multiply defined symbols. I tested it a bit and it seems that when a convenience library is linked into a _program_, libtool will just pass the static .a file directly to the linker, without unpacking, using whole archive mode or doing anything particularly special. I guess this is fine because presumably portable programs cannot tell the difference. Because of this behaviour, duplicate objects in convenience libraries may not be a significant problem in practice for linking programs. With normal linkers, individual object files that resolve undefined symbols are effectively picked out of the archive one at a time until there are no remaining undefined symbols that could be resolved by the library. So once one of the duplicate objects is picked, the other is essentially removed from consideration since it does not provide different symbols. I'm not sure if there are any historical exceptions to this linker behaviour that would affect portability of a package depending on this. You will almost certainly get multiple definition errors if you tried to link such a convenience library into a shared libtool library. Cheers, Nick
