If it is a link order problem, why isn’t this problem a more common occurrence for other modules? It appears the dynamic libs generated by the various gnuradio components do have cyclic dependencies. For example ldd on the following libraries yields:
libgnuradio-runtime: pmt libgnuradio-digital: analog,filter,fft,blocks,runtime,pmt libgnuradio-treliis: digital,analog,filter,fft,blocks,runtime,pmt Because the order is crucial into g++, I am wondering if “-Wl,—start-group <libs> —end-group” linker option is appropriate. My understanding is this forces the linker to continually look for the symbols in the libraries specified to resolve cyclic dependencies. The tradespace is longer linking times, but that is not of concern for me if it links. It is also not clear from “man ld” or other resources (e.g. Stack Exchange) if this linker option works for dynamic libraries, or just static ones. Now we are really in the weeds! PWG On Nov 17, 2016, at 9:30 AM, Garver, Paul W <[email protected]<mailto:[email protected]>> wrote: The module library builds without linker errors. The block which calls viterbi_algorithm_combined() is rfid_decode. [12%] Linking CXX shared library libgnuradio-pwg-1.0.0git.so /usr/bin/c++ -fPIC -O3 -DNDEBUG -shared -Wl,-soname,libgnuradio-pwg-1.0.0git.so.0.0.0 -o libgnuradio-pwg-1.0.0git.so.0.0.0 CMakeFiles/gnuradio-pwg.dir/rfid_decode_impl.cc.o CMakeFiles/gnuradio-pwg.dir/rfid_channel_switch_impl.cc.o -lboost_filesystem -lboost_system /usr/local/lib/libgnuradio-runtime.so /usr/local/lib/libgnuradio-pmt.so /usr/local/lib/libgnuradio-digital.so /usr/local/lib/libgnuradio-trellis.so -Wl,-rpath,/usr/local/lib: [ 12%] Built target gnuradio-pwg But the pure C++ test harness fails to link properly: [ 95%] Building CXX object examples/c++/CMakeFiles/rfid_dec_harness.dir/rfid_dec_harness.cc.o [100%] Linking CXX executable rfid_dec_harness /usr/bin/c++ -O3 -DNDEBUG CMakeFiles/rfid_dec_harness.dir/rfid_dec_harness.cc.o -o rfid_dec_harness -rdynamic ../../lib/libgnuradio-pwg-1.0.0git.so.0.0.0 -lgnuradio-blocks -lboost_filesystem -lboost_system /usr/local/lib/libgnuradio-runtime.so /usr/local/lib/libgnuradio-pmt.so /usr/local/lib/libgnuradio-digital.so /usr/local/lib/libgnuradio-trellis.so -Wl,-rpath,/home/paul/git_repos/gr-pwg/build/lib:/usr/local/lib: ../../lib/libgnuradio-pwg-1.0.0git.so.0.0.0: undefined reference to `void gr::trellis::viterbi_algorithm_combined<float, unsigned char>(int, int, int, std::vector<int, std::allocator<int> > const&, std::vector<int, std::allocator<int> > const&, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > const&, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > const&, int, int, int, int, std::vector<float, std::allocator<float> > const&, gr::digital::trellis_metric_type_t, float const*, unsigned char*)' collect2: error: ld returned 1 exit status The symbol exists in libgnuradio-trellis! nm /usr/local/lib/libgnuradio-trellis.so | grep -i viterbi_algorithm_combined | c++filt 000000000007df30 t void gr::trellis::viterbi_algorithm_combined<float, unsigned char>(int, int, int, std::vector<int, std::allocator<int> > const&, std::vector<int, std::allocator<int> > const&, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > const&, std::vector<std::vector<int, std::allocator<int> >, std::allocator<std::vector<int, std::allocator<int> > > > const&, int, int, int, int, std::vector<float, std::allocator<float> > const&, gr::digital::trellis_metric_type_t, float const*, unsigned char*) Now, I know order matters into g++. I've tried various linking orders to no avail. I just do not understand why g++ can't find the symbol. ________________________________ From: Michael Dickens <[email protected]<mailto:[email protected]>> Sent: Thursday, November 17, 2016 11:04:09 AM To: Garver, Paul W Cc: [email protected]<mailto:[email protected]> Subject: Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux) The lib/ and swig/ libraries used inside cmake are generally the same. I'll be very curious how this issue pans out! Cheers! - MLD On Thu, Nov 17, 2016, at 08:13 AM, Garver, Paul W wrote: I’m thinking I should write a simple C++ harness to call the block. That way, I can isolate a SWIG problem from a block/C++ issue. Should the SWIG link libraries (GR_SWIG_LIBRARIES) be different from the libraries used in the lib directory? _______________________________________________ Discuss-gnuradio mailing list [email protected]<mailto:[email protected]> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
