[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Favoring static linking at configure time

From: Benoit Sigoure
Subject: Re: Favoring static linking at configure time
Date: Tue, 4 Dec 2007 19:02:58 +0100

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]