Re: libtool 1.5 -static and installed libraries

[Ralf Wildenhues]

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