[CMake] Static linking and find_library

S. Levent Yilmaz leventyilmaz at gmail.com
Wed May 13 15:27:07 EDT 2009


On Mon, May 11, 2009 at 1:39 PM, Brad King <brad.king at kitware.com> wrote:
> Bill Hoffman wrote:
>>
>> Marcel Loose wrote:
>>>
>>> 2) How can I persuade find_library() to only search for static
>>> libraries?
>>>
>> You can't.
>
> Yes, you can:
>
>  find_library(MATH_LIB NAMES libm.a)
>
> If you specify a valid library name then CMake will look for it directly
> instead of prepending 'lib' and appending library extensions.
>
> The reason there is no generic "find a static library" option is because
> it is almost impossible to implement on windows where one cannot
distinguish
> import libraries and static libraries by their name.
>

Based on my experience, the necessity to enforce static links is almost
always a platform specific issue (cf. computing clusters). And therefore,
dare I say, CMakeLists.txt is not the place to enforce this, and certainly
having to input platform specific stuff in my CMakeLists.txt is quite
tiresome to say the least. (moreover, in such setting, the complication with
windows and friends is irrelevant).

So, if I may, let me shift the question a little bit: How can one enforce
static linkage on a per platform basis (not the whole project)? In other
words, what setting can we insert into a toolchain
file<http://www.vtk.org/Wiki/CMake_Cross_Compiling>to make this
possible?

Let me identify a problem here with find_library(). Here is a repeatable
scenario; take the following 3 line CMakeLists.txt:
project( foo CXX )
cmake_minimum_required(VERSION 2.6)
find_library( FOO_LIBRARY foo ENV LD_LIBRARY_PATH )

where somewhere in the list LD_LIBRARY_PATH there exists libfoo.so and libfoo.a
(replace foo with an actual lib in your environment). Then with CMake 2.6.x
or today's HEAD version, run cmake in the following 4 different ways:

   1. cmake ..
   2. cmake -DCMAKE_SYSTEM_NAME=Generic ..
   3. cmake -DCMAKE_SYSTEM_NAME=Catamount ..
   4. cmake -DCMAKE_TOOLCHAIN_FILE=sysbar.cmake ..

Case (1) will yield libfoo.so, case (2) will yield libfoo.so, and case (3)
will yield libfoo.a.  Case (4) uses a custom crafted toolchain file, let's
leave that for later.

Confusion grows deeper once one digs into the Platform files.. Take the line
(and the only line) in share/cmake-2.x/Modules/Platform/Generic.cmake:

SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)

and it seems to have no effect. [..]Platform/Catamount.cmake  also has this
line along with bunch of other stuff, and it successfully "forces"
find_library() to get to the static library. In Case(4) the custom toolchain
file sysbar.cmake is nothing but  set(CMAKE_SYSTEM_NAME Generic) followed by
the rest of the stuff in Catamount.cmake. Case(4), quite confusingly, finds
libfoo.so!!

Sorry for the long message, but I really tried to condense it as much as I
could. Any ideas?


- Levent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20090513/d751a4d8/attachment.htm>


More information about the CMake mailing list