Re: [Discuss-gnuradio] undefined reference to file_sink_base

[Marcus Müller]

Ha! good catch; after you added BLOCKS to the REQUIRED_COMPONENTS list in CMake, you might want to completely delete the build/ folder and start anew. CMake occasionally misses such changes.

Best regards,
Marcus

On 11/05/2015 06:14 PM, Nemanja Savic wrote:

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:
address@hidden 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:
address@hidden 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 <address@hidden> 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
>
> address@hidden 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 <address@hidden>
> 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 <address@hidden>
>> 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 <address@hidden
>>>> 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 <
>> address@hidden>
>>>>> 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 address@hidden://
>> lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Discuss-gnuradio mailing list
>>>>>> address@hidden
>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>>
>>>>>>
>>>>> --
>>>>> Nemanja Savić
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Nemanja Savić
>>>>
>>>
>>
>

--

Nemanja Savić