Favoring static linking at configure time

[Benoit Sigoure]

Hello list,
I wrote a set of macros to detect the Boost libraries.  So far so  
good.  Say that you have libboost_whatever.so (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