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? -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
