On Mon, May 11, 2009 at 1:39 PM, Brad King <<a href="mailto:brad.king@kitware.com" target="_blank">brad.king@kitware.com</a>> wrote:<br>> Bill Hoffman wrote:<br>>><br>>> Marcel Loose wrote:<br>>>><br>
>>> 2) How can I persuade find_library() to only search for static<br>
>>> libraries?<br>>>><br>>> You can't.<br>><br>> Yes, you can:<br>><br>> find_library(MATH_LIB NAMES libm.a)<br>><br>> If you specify a valid library name then CMake will look for it directly<br>
> instead of prepending 'lib' and appending library extensions.<br>><br>> The reason there is no generic "find a static library" option is because<br>> it is almost impossible to implement on windows where one cannot distinguish<br>
> import libraries and static libraries by their name.<br>><br><br>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). <br>
<br>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 <a href="http://www.vtk.org/Wiki/CMake_Cross_Compiling" target="_blank">toolchain file</a> to make this possible? <br>
<br>Let me identify a problem here with find_library(). Here is a repeatable scenario; take the following 3 line CMakeLists.txt: <div><div><br></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace;">project( foo CXX )</span></div>
<div><span class="Apple-style-span" style="font-family: 'courier new', monospace;">cmake_minimum_required(VERSION 2.6)</span></div>
<div><span class="Apple-style-span" style="font-family: 'courier new', monospace;">find_library( FOO_LIBRARY foo ENV LD_LIBRARY_PATH )</span><br></div><div><br></div><div>where somewhere in the list LD_LIBRARY_PATH there exists libfoo.so <span class="Apple-style-span" style="font-style: italic;">and</span> 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:</div>
<div><ol><li><span class="Apple-style-span" style="font-family: 'courier new', monospace;">cmake ..<br></span></li><li><span class="Apple-style-span" style="font-family: 'courier new', monospace;">cmake -DCMAKE_SYSTEM_NAME=Generic ..<br>
</span></li><li><span class="Apple-style-span" style="font-family: 'courier new', monospace;">cmake -DCMAKE_SYSTEM_NAME=Catamount ..<br></span></li><li><span class="Apple-style-span" style="font-family: 'courier new', monospace;">cmake -DCMAKE_TOOLCHAIN_FILE=sysbar.cmake ..<br>
</span></li></ol></div><div>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. <br></div></div><div>
<div><br></div><div>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:<br></div><div><br></div><div><span class="Apple-style-span" style="font-family: 'courier new', monospace;">SET_PROPERTY(GLOBAL PROPERTY TARGET_SUPPORTS_SHARED_LIBS FALSE)<br>
</span></div><div><br></div><div>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!! </div>
<div><br></div><div>Sorry for the long message, but I really tried to condense it as much as I could. Any ideas? </div><div><br></div><div><br></div><div>- Levent</div><div><br></div></div>