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 <[email protected]> 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 <[email protected]>
> 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:
>> [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 <[email protected]>
>> 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 <
>>> [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ć
>>
>>
>>
>
>
> --
> Nemanja Savić
>



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

Reply via email to