Hi Howard, Alexandre, others, * Howard Chu wrote on Sun, Aug 28, 2005 at 10:19:03PM CEST: > We just migrated from libtool-1.4.3 to 1.5.18 in the OpenLDAP CVS HEAD, > and are seeing a new linking problem.
You've migrated *already*? :-) > By default we link with -static so > that our local libtool-generated libraries get statically linked. But we > don't use -all-static; we don't want to alter the default linking for > system-installed libraries. OK. > On SuSE 9.x when the libdb devel RPM is installed, a libdb.la file is > also installed, and libtool 1.5 finds and reads this file. In this case, > libtool chooses to link the static libdb into our slapd executable, > rather than the shared library, even though the .la file says > "installed=yes". This results in an unusable binary on SuSE 9.x because > the default static library doesn't support thread-local storage/NPTL, > while the default C library requires it. (But if the shared library is > used instead, the runtime linker can locate the correct libdb.) OK. Sounds like a reasonable setup. > So the question is, why does linking with -static cause libtool to > behave like -all-static was used, why does it ignore the installed > status of the libraries? (You also sent a patch to change this behavior to match the current, i.e., both branch-1-5 and CVS HEAD, documentation). Now while your patch looks ok at a glance, I'm unsure whether what is wanted by users is what the documentation says or what the current code does. See for example this discussion between Akim and Alexandre about the issue: http://lists.gnu.org/archive/html/libtool/2005-01/msg00350.html Should we discuss this and decide about what's best? Maybe we'd need another switch to link statically against all non-system libs (in the sense that libc is one, but libdb is not)? Or would implementing per- deplib static/shared switches be the only solution? Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
