[Top][All Lists]

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

Favoring static linking at configure time

From: Benoit Sigoure
Subject: Favoring static linking at configure time
Date: Tue, 4 Dec 2007 18:38:26 +0100

Hello list,
I wrote a set of macros to detect the Boost libraries. So far so good. Say that you have (on a GNU/Linux platform, but that doesn't matter) AND libboost_whatever.a in the same folder. At configure time, what I do is that I try to see whether g++ -L/path/to/boost/lib -lboost_whatever works or not. Now, say that the packager would like to specify that if the static version of the library is available, then by all means please use it rather than the shared one. Is this possible, if yes how?

1st problem: static archives aren't always named in libfoo.a (but it's *mostly* the case, as opposed to the naming conventions for 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? 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). 3rd problem: running libtool at configure time. Is this possible? Do I want to do this? Libtool has a -all-static flag that *might* help me (I'm not sure).

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?

Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

reply via email to

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