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
