[CMake] Why bother with FIND_LIBRARY()

[William A. Hoffman]

I just tried what you suggest with the SGI CC compiler and it does not seem to work:


[itk at rapture ~/<1>MyTests/CMake-CC]% CC -l/usr/lib/libmutex.so
C++ prelinker: warning: could not locate library -l/usr/lib/libmutex.so; assuming /usr/lib/lib/usr/lib/libmutex.so.a
ld32: FATAL   9  : I/O error (-l/usr/lib/libmutex.so): No such file or directory
[itk at rapture ~/<1>MyTests/CMake-CC]% CC -llibmutex.so
C++ prelinker: warning: could not locate library -llibmutex.so; assuming /usr/lib/liblibmutex.so.a
ld32: FATAL   9  : I/O error (-llibmutex.so): No such file or directory
[itk at rapture ~/<1>MyTests/CMake-CC]% CC -lmutex.so
C++ prelinker: warning: could not locate library -lmutex.so; assuming /usr/lib/libmutex.so.a
ld32: FATAL   9  : I/O error (-lmutex.so): No such file or directory
[itk at rapture ~/<1>MyTests/CMake-CC]% CC -lmutex.so -L/usr/lib
C++ prelinker: warning: could not locate library -lmutex.so; assuming /usr/lib/libmutex.so.a
ld32: FATAL   12 : Expecting n32 objects: /usr/lib/crt1.o is o32.
[itk at rapture ~/<1>MyTests/CMake-CC]% CC -L/usr/lib -lmutex.so 
C++ prelinker: warning: could not locate library -lmutex.so; assuming /usr/lib/libmutex.so.a
ld32: FATAL   12 : Expecting n32 objects: /usr/lib/crt1.o is o32.
[itk at rapture ~/<1>MyTests/CMake-CC]% CC -L/usr/lib -lmutex
ld32: FATAL   12 : Expecting n32 objects: /usr/lib/crt1.o is o32.
[itk at rapture ~/<1>MyTests/CMake-CC]% 


I am pretty sure -l has to have foo where libfoo.a or libfoo.so is in the -L path.

Gcc does not seem to like it either:
kitware at hythloth $ gcc -l/usr/lib/libpamc.so                                                                                     ~
/usr/bin/ld: cannot find -l/usr/lib/libpamc.so
collect2: ld returned 1 exit status

kitware at hythloth $ gcc -lpamc                                                                                                    ~
/usr/lib/gcc-lib/i486-linux/3.3.3/../../../crt1.o(.text+0x18): In function `_start':
../sysdeps/i386/elf/start.S:98: undefined reference to `main'



-Bill

At 04:20 PM 10/27/2004, Brad King wrote:
>Eric Bolz wrote:
>>I've been using FIND_LIBRARY do locate all of the libraries my project needs.  I've noticed, however the libraries I find are not necessarily the ones that get linked. For example, say I do the following:
>>FIND_LIBRARY(LIB_1    NAMES  m         PATHS /usr/lib)
>>FIND_LIBRARY(LIB_2    NAMES  socket  PATHS  /usr/local/lib)
>>TARGET_LINK_LIBRARIES( my_executable   ${LIB_1}  ${LIB_2})
>>In my Makefile, I get something like this:
>>gcc   -L/usr/lib  -L/usr/local/lib -lm  -lsocket
>>The problem is that even though I did all the work of locating the socket library in /usr/local/lib, I can't be sure that the linker won't pick up a different one from /usr/lib
>>cmake could do the following:
>>gcc  -l/usr/lib/libm.a  -l/usr/local/lib/libsocket.a
>>Why does cmake separate the library name from the path?
>>This make me wonder about the value of FIND_LIBRARY().  Why bother with FIND_LIBRARY if cmake is going to ignore what I found?  Is there some benefit to FIND_LIBRARY() I'm not aware of?
>
>CMake separates the -L and -l portions because some linkers will copy the entire static library in if a full path is given.  However, these tests were done with specyfing "/usr/lib/libfoo.a" instead of "-l/usr/lib/libfoo.a", so your solution may work.  It will have to be tested across many platforms, though.  Please submit this to the bug tracker:
>
>http://www.cmake.org/Bug
>
>Thanks,
>-Brad
>_______________________________________________
>CMake mailing list
>CMake at www.cmake.org
>http://www.cmake.org/mailman/listinfo/cmake