Maybe this can help somebody to help me. So, I have my .so library installed (from the time when building was possible ;)) Now, when I run ldd on installed and built library I get following: existing: [savi_ne@ts-070046nl build]$ ldd /usr/local/lib64/libgnuradio-TMS.so linux-vdso.so.1 => (0x00007ffd0cfab000) libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5 (0x00007f75c9b01000) libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5 (0x00007f75c98fd000) libgruel-3.6.5.1.so.0.0.0 => /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0 (0x00007f75c96b7000) libgnuradio-core-3.6.5.1.so.0.0.0 => /usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x00007f75c9221000) libgnuradio-blocks-3.6.5.1.so.0.0.0 => /usr/local/lib64/libgnuradio-blocks-3.6.5.1.so.0.0.0 (0x00007f75c8e2b000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f75c8b25000) libm.so.6 => /lib64/libm.so.6 (0x00007f75c88a1000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f75c868a000) libc.so.6 => /lib64/libc.so.6 (0x00007f75c82f6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f75c80d9000) librt.so.1 => /lib64/librt.so.1 (0x00007f75c7ed0000) libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5 (0x00007f75c7cbe000) libboost_program_options-mt.so.5 => /usr/lib64/libboost_program_options-mt.so.5 (0x00007f75c7a71000) libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5 (0x00007f75c785b000) libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x00007f75c7565000) libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3 (0x00007f75c735f000) libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0 (0x00007f75c7049000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f75c6e45000) liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x00007f75c6bc5000) /lib64/ld-linux-x86-64.so.2 (0x00007f75c9fbd000)
The one that makses problem: [savi_ne@ts-070046nl build]$ ldd lib/libgnuradio-TMS.so linux-vdso.so.1 => (0x00007fff83398000) libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5 (0x00007f42e79bd000) libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5 (0x00007f42e77b9000) libgruel-3.6.5.1.so.0.0.0 => /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0 (0x00007f42e7573000) libgnuradio-core-3.6.5.1.so.0.0.0 => /usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x00007f42e70dd000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f42e6dd6000) libm.so.6 => /lib64/libm.so.6 (0x00007f42e6b52000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f42e693c000) libc.so.6 => /lib64/libc.so.6 (0x00007f42e65a7000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f42e638a000) librt.so.1 => /lib64/librt.so.1 (0x00007f42e6182000) libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5 (0x00007f42e5f6f000) libboost_program_options-mt.so.5 => /usr/lib64/libboost_program_options-mt.so.5 (0x00007f42e5d22000) libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5 (0x00007f42e5b0d000) libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x00007f42e5816000) libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3 (0x00007f42e5610000) libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0 (0x00007f42e52fb000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f42e50f6000) liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x00007f42e4e76000) /lib64/ld-linux-x86-64.so.2 (0x00007f42e7e5e000) As you can see, I marke with red, the complete line about blocks library is missing in the newly built library. Cheers and thanx On Thu, Nov 5, 2015 at 5:53 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hm, that really was my hope. Sorry, I'm out of ideas. > > On 11/05/2015 05:39 PM, Nemanja Savic wrote: > > everything looks fine with that > > > > [savi_ne@ts-070046nl build]$ ldd lib/libgnuradio-TMS.so > > linux-vdso.so.1 => (0x00007ffd93fa1000) > > libboost_filesystem-mt.so.5 => /usr/lib64/libboost_filesystem-mt.so.5 > > (0x00007fccb7e5f000) > > libboost_system-mt.so.5 => /usr/lib64/libboost_system-mt.so.5 > > (0x00007fccb7c5b000) > > libgruel-3.6.5.1.so.0.0.0 => > /usr/local/lib64/libgruel-3.6.5.1.so.0.0.0 > > (0x00007fccb7a15000) > > libgnuradio-core-3.6.5.1.so.0.0.0 => > > /usr/local/lib64/libgnuradio-core-3.6.5.1.so.0.0.0 (0x00007fccb757f000) > > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fccb7278000) > > libm.so.6 => /lib64/libm.so.6 (0x00007fccb6ff4000) > > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fccb6dde000) > > libc.so.6 => /lib64/libc.so.6 (0x00007fccb6a49000) > > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fccb682c000) > > librt.so.1 => /lib64/librt.so.1 (0x00007fccb6624000) > > libboost_date_time-mt.so.5 => /usr/lib64/libboost_date_time-mt.so.5 > > (0x00007fccb6411000) > > libboost_program_options-mt.so.5 => > > /usr/lib64/libboost_program_options-mt.so.5 (0x00007fccb61c4000) > > libboost_thread-mt.so.5 => /usr/lib64/libboost_thread-mt.so.5 > > (0x00007fccb5faf000) > > libfftw3f.so.3 => /usr/lib64/libfftw3f.so.3 (0x00007fccb5cb8000) > > libfftw3f_threads.so.3 => /usr/lib64/libfftw3f_threads.so.3 > > (0x00007fccb5ab2000) > > libvolk.so.0.0.0 => /usr/local/lib64/libvolk.so.0.0.0 > > (0x00007fccb579d000) > > libdl.so.2 => /lib64/libdl.so.2 (0x00007fccb5598000) > > liborc-0.4.so.0 => /usr/lib64/liborc-0.4.so.0 (0x00007fccb5318000) > > /lib64/ld-linux-x86-64.so.2 (0x00007fccb8300000) > > > > Core library is there I checked. I also tried with nm to look for symbols > > inside core library and they are really there. > > > > > > On Thu, Nov 5, 2015 at 5:29 PM, Marcus Müller <marcus.muel...@ettus.com> > > wrote: > > > >> Hm, make sure your program really uses those; "ldd libgnuradio-TMS.so" > >> might point to the right places. > >> > >> On 11/05/2015 05:21 PM, Nemanja Savic wrote: > >>> Anything else I could try with this silly problem? I am sure 100% that > >>> libraries are in /usr/local/lib64 > >>> > >>> On Thu, Nov 5, 2015 at 5:12 PM, Nemanja Savic <vlasi...@gmail.com> > >> wrote: > >>>> In my gnuradio 3.6.5.1 file_sink_base constructor takes otwo > arguments, > >>>> filename and bool. > >>>> > >>>> On Thu, Nov 5, 2015 at 5:06 PM, Marcus Müller < > marcus.muel...@ettus.com > >>>> wrote: > >>>> > >>>>> Does it get better when you do blocks::file_sink_base(filename, true, > >>>>> false)? > >>>>> > >>>>> > >>>>> On 11/05/2015 05:04 PM, Nemanja Savic wrote: > >>>>> > >>>>> This is rather strange. This module was working ok, I just didn't > build > >>>>> it for quite some time. > >>>>> I use file_sink_base as a base class for one of my file sinks that > has > >>>>> some kind of history buffer inside. > >>>>> And, the structure of that block is identical as the structure of > >>>>> file_sink that comes with GR. > >>>>> So my block is defined as > >>>>> class TMS_API file_sink_lim_b : virtual public gr_sync_block, > >>>>> virtual public > >> blocks::file_sink_base > >>>>> pretty much as normal file sink, except I have blocks:: namsespace. > >>>>> Inside the constructor is also the same: > >>>>> blocks::file_sink_base(filename, true). > >>>>> > >>>>> > >>>>> > >>>>> On Thu, Nov 5, 2015 at 3:57 PM, Marcus Müller < > >> marcus.muel...@ettus.com> > >>>>> wrote: > >>>>> > >>>>>> Hi Nemanja, > >>>>>> > >>>>>> file_sink_base only has a parameterless public constructor these > days > >>>>>> (from gr-blocks/include/.../file_sink_base.h) > >>>>>> 47 protected: > >>>>>> 48 file_sink_base(const char *filename, bool is_binary, bool > >>>>>> append); > >>>>>> 49 > >>>>>> 50 public: > >>>>>> 51 file_sink_base() {} > >>>>>> 52 ~file_sink_base(); > >>>>>> 53 > >>>>>> and the protected one takes a second bool now. > >>>>>> That doesn't explain the problems with the d'tor and do_update, but > >>>>>> maybe it's a start. > >>>>>> > >>>>>> Best regards, > >>>>>> Marcus > >>>>>> > >>>>>> > >>>>>> On 11/05/2015 01:50 PM, Nemanja Savic wrote: > >>>>>> > >>>>>> Hi all guys, > >>>>>> > >>>>>> i have encountered a new problem which was not present before. I > have > >> my > >>>>>> old GR module (out of tree) for years. Yesterday I wanted to change > >>>>>> something and couldn't build it cause of the linker error. > >>>>>> > >>>>>> libgnuradio-TMS.so: undefined reference to > >>>>>> `gr::blocks::file_sink_base::file_sink_base(char const*, bool)' > >>>>>> libgnuradio-TMS.so: undefined reference to > >>>>>> `gr::blocks::file_sink_base::~file_sink_base()' > >>>>>> libgnuradio-TMS.so: undefined reference to > >>>>>> `gr::blocks::file_sink_base::do_update()' > >>>>>> > >>>>>> I know that before, I had similar error on some other machine, so I > >>>>>> added lines: > >>>>>> > >>>>>> set(GR_REQUIRED_COMPONENTS CORE BLOCKS) > >>>>>> find_package(Gnuradio "3.6.5.1") > >>>>>> > >>>>>> in my top CMakeLists.txt file but unfortunately nothing changed. I > am > >>>>>> sure that everything is there, but can't figure out why it can't > find > >> it. > >>>>>> Cheers and thanx, > >>>>>> -- > >>>>>> Nemanja Savić > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Discuss-gnuradio mailing listDiscuss-gnuradio@gnu.orghttps:// > >> lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Discuss-gnuradio mailing list > >>>>>> Discuss-gnuradio@gnu.org > >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >>>>>> > >>>>>> > >>>>> -- > >>>>> Nemanja Savić > >>>>> > >>>>> > >>>>> > >>>> -- > >>>> Nemanja Savić > >>>> > >>> > >> > > > > -- Nemanja Savić
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio