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 <[email protected]>
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 <[email protected]>
> 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 <[email protected]
> >
> >> 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 <
> [email protected]>
> >>> 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 [email protected]://
> lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Discuss-gnuradio mailing list
> >>>> [email protected]
> >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >>>>
> >>>>
> >>>
> >>> --
> >>> Nemanja Savić
> >>>
> >>>
> >>>
> >>
> >> --
> >> Nemanja Savić
> >>
> >
> >
>
>


-- 
Nemanja Savić
_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to