Re: Favoring static linking at configure time

[Benoit Sigoure]

On Dec 4, 2007, at 6:49 PM, Brian Dessent wrote:

> 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.

Alright but I don't care about the w32api, I only care about Boost  
libraries, in this context.

> > 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

Hmm I didn't know this.  How portable is it?  I guess a gccism, but  
is it even portable across versions/ports of GCC?

> > 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.


That could be a way out when $GXX is `yes', but I'd love a more  
general solution.  Especially because I happen to use other compilers  
than just GCC.

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory