Re: [Discuss-gnuradio] Linking gr-digital in OOT Module (Success on OSX, fails on Linux)

[Garver, Paul W]

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 <address@hidden> 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 <address@hidden>
Sent: Thursday, November 17, 2016 11:04:09 AM
To: Garver, Paul W
Cc: address@hidden
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
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio