[CMake] TARGET_LINK_LIBRARIES question

Bill Hoffman hoffman.mlist at gmail.com
Wed Apr 11 10:05:53 EDT 2007


Thomas Christian Chust wrote:
> a.neundorf-work at gmx.net wrote:
>
>   
>> david.rhoda at kodak.com wrote:
>>
>>     
>>> [...]
>>> When I TARGET_LINK_LIBRARIES( test /path/to/libA.lib) I get the equivalent
>>> of -L /path/to -l libA.lib.  I'd like to get -l /path/to/libA.lib.  Is
>>> that possible?
>>>       
>> Currently this is not possible. You also shouldn't need it. CMake orders the 
>> directories so that you should get the libs you want.
>> Do you have a case where this doesn't work ?
>> [...]
>>     
>
>
> Hello,
>
> most of the time this behaviour of CMake is very desirable, but I have
> been running into trouble with it on MacOS X.
>
> When both a shared and a static library of the same name exist (as is
> often the case with libraries installed by libtool based builds), the
> linker flags computed by CMake always reference the shared library (even
> if it is in a directory different from the static one and even if this
> directory is later on the library search path) and if you don't want
> that, you have to construct all the flags by hand or uninstall the
> shared library :-(
>
> I posted this problem earlier on this list, but nobody came up with a
> good solution for it. I also don't know if there really is a good
> solution or if one should consider the Mach-O linker design broken ;-)
>   

   -search_paths_first
              By  default  when  the  -dynamic  flag is in effect, the 
-lx and
              -weak-lx  options  first  search  for  a  file   of   
the   form
              `libx.dylib'  in each directory in the library search 
path, then
              a file of the form `libx.a'  is  searched  for  in  the  
library
              search  paths.   This  option  changes  it  so that in 
each path
              `libx.dylib' is searched for then `libx.a' before the 
next  path
              in the library search path is searched.

If you add that to LDFLAGS before you run cmake it should fix the 
problem.   At one point,
I thought we made this a default flag in CMake.  I guess it never got 
commited, what
do you mac folks think, should this be a default flag for cmake on OS X?

-Bill



More information about the CMake mailing list