Re: [Discuss-gnuradio] cmake build not placing lib*.so properly

[Josh Blum]

On 01/13/2012 11:34 AM, Marcus D. Leech wrote:
> On 13/01/12 02:21 PM, Josh Blum wrote:
>>
>> On 01/13/2012 11:01 AM, Marcus D. Leech wrote:
>>   
>>> Observe the following directory listing:
>>>
>>> address@hidden ~]$ ls -l /usr/local/lib/libgnuradio-core*
>>> lrwxrwxrwx 1 root root      34 2012-01-13 13:56
>>> /usr/local/lib/libgnuradio-core-3.5.2git.so.0 ->
>>> libgnuradio-core-3.5.2git.so.0.0.0
>>> lrwxrwxrwx 1 root root      34 2012-01-13 13:56
>>> /usr/local/lib/libgnuradio-core.so -> libgnuradio-core-3.5.2git.so.0.0.0
>>> -rwxr-xr-x 1 root root 2108365 2012-01-13 13:45
>>> /usr/local/lib/libgnuradio-core.so.0.0.0
>>>
>>> Notice how libgnuradio-core.so  points off to nothingness
>>>
>>> Now, gnuradio-based *applications* seem to be just fine with this, after
>>> running ldconfig.
>>>
>>> But, for example, if you pull something, like gr-stream-tags off of
>>> CGRAN, and try to build the result, it
>>>   will barf on a linker error, due to not being able to resolve
>>> "-lgnuradio-core" (and others).
>>>
>>> So the question is, where is cmake getting its notion of how to name
>>> these things, and set up the
>>>   symlink hierarchy?  If it comes from the ".pc" files, I'll note that
>>> they haven't been updated since
>>>   I last ran an autotools build, 5 days ago.  Does cmake update the
>>> ".pc" files?  How is this
>>>   dangling symlink problem happening?
>>>
>>>
>>>     
>> The weirdness comes from this code:
>> http://gnuradio.org/cgit/gnuradio.git/tree/cmake/Modules/GrMiscUtils.cmake?h=maint#n151
>>
>> The symlinks looks like this on my system:
>> http://pastebin.com/Q4Vuz8Kb
>>
>> What is your os? I think this line for you isnt changing the library
>> target name to ${target}-${LIBVER}. Does that sound like the issue?
>>
>> set_target_properties(${target} PROPERTIES LIBRARY_OUTPUT_NAME
>> ${target}-${LIBVER} SOVERSION "0.0.0")
>>
>> -Josh
>>
>>
>>   
> It's a Fedora-12 32-bit machine.  With cmake-2.6.4-5.fc12.i686
> 

Thats an old fedora :-)

> That could be the issue, yes.  But I'm not a Cmake guy at all.
> 
> 
> 
This is part of our special LIBRARY_EXTRAS mode. You can disable it with
-DLIBRARY_EXTRAS=OFF just so you know, but I think the following patch
will solve the issue...

So, it like cmake 2.6 doesnt have LIBRARY_OUTPUT_NAME, but it does have
OUTPUT_NAME. They are both ways to rename the target, one being specific
to a library and only possible with 2.8 and up. Try this patch:
http://pastebin.com/kXKgJPF7

-josh