Re: Favoring static linking at configure time

[Brian Dessent]

Benoit Sigoure wrote:

> shared libraries).  The first case that comes to my mind is Windows
> where there used to be import libraries named in libfoo.a (whereas
> they are now named libfoo.dll.a or whatever).  But maybe this was a
> long time ago so it's not common enough to bother?

Every one of the w32api import libraries is named according to the old
scheme so yes this is still extremely common and won't be going away any
time soon.  You really shouldn't have to care what the filename is
though.

> 2nd problem: when you use -lfoo, GCC (at least) seems to always use
> libfoo.{so,dylib,sl,you-name-it} rather than libfoo.a.  AFAIK there
> is no switch to kindly ask it to use the .a version (what people do
> usually is that they pass the full path to the .a on the link command
> line).

Of course there is: -Wl,-Bstatic -lfoo -Wl,-Bdynamic

> So yeah the general question basically boils down to: is it possible
> to test at configure time whether a static version of a given library
> is available and ensure that it's used during the build?

I'm not sure how you'd do this with libtool per se, but in general why
can't you just try a test link with -Bstatic -lfoo, if that succeeds
then use that, otherwise fall back to just -lfoo.

Brian