On 01/13/2012 11:01 AM, Marcus D. Leech wrote: > Observe the following directory listing: > > [mleech@localhost ~]$ 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
