Re: [Discuss-gnuradio] undefined reference to file_sink

On Fri, Nov 6, 2015 at 7:43 PM, Alexandre Raymond <address@hidden> wrote:

Hi Nemanja,

You can check the commands being executed by cmake using the following
command in your build directory:
VERBOSE=1 make

Can you post the command that builds libgnuradio-TMS.so and any
associated messages?

Regards,
Alexandre

On Fri, Nov 6, 2015 at 9:19 AM, Nemanja Savic <address@hidden> wrote:
> How can I check/add -L and then path to the gnuradio blocks library in order
> to force setup to use it? Or maybe I am on th ewrong way?
>
> On Thu, Nov 5, 2015 at 6:25 PM, Nemanja Savic <address@hidden> wrote:
>>
>> Tried that already a few times and nothing. Is there any so called cash
>> where cmake can mix something up. I was recently building gnuradio 3.7.8 and
>> I think that administrator also removed all my manually installed packages
>> and did package reset to default.
>>
>> On Thu, Nov 5, 2015 at 6:17 PM, Marcus Müller <address@hidden>
>> wrote:
>>>
>>> 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ć
>>>
>>>
>>
>>
>>
>> --
>> Nemanja Savić
>
>
>
>
> --
> Nemanja Savić
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>

Nemanja Savić

From:	Nemanja Savic
Subject:	Re: [Discuss-gnuradio] undefined reference to file_sink_base
Date:	Fri, 6 Nov 2015 20:11:39 +0100

Re: [Discuss-gnuradio] undefined reference to file_sink_base