Re: Using libtool 2.0 in autoconf tests

[Kevin P. Fleming]

Gary V. Vaughan wrote:

> Sander, if you want to check whether a particular library is shared,
> we should be able to write a macro for you to figure that out without
> actually needing to roll and run an entire libtool script.  Or is
> there more to your problem than that?

There _is_ more to his problem than that; I have run into this situation 
as well.

Here's the rub: at configure time, you want to check if a particular 
library is available, and will be linkable into your project when its 
needed. This is done using AC_CHECK_LIB and checking for a particular 
function (usually an init function) to be present in the library.

What happens if the only version of the library present is libfoo.a, but 
the configure script has been passed --disable-static? AC_CHECK_LIB will 
succeed, but final linking will fail.

What happens if the .la file is in the library search path, but the 
.a/.so files are not? AC_CHECK_LIB will fail, but final linking would 
have succeeded. (I'll grant that this is an abnormal situation, but I've 
had reports of it).

What happens if the shared library being linked to has dependent 
libraries (and was installed using libtool), and you are building on a 
platform that does not automatically link in shared deplibs? 
AC_CHECK_LIB will fail, but using libtool for linking would succeed.

I can probably come up with a dozen more situations where using libtool 
for library link testing _at configure time_ is really necessary, and 
not having it makes our projects work less well than they should. Like 
Sander, I have built some home-grown autoconf macros to use libtool for 
link testing at configure time, and if libtool-2.0 will no longer 
support this activity I'll have a significant problem.