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
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
