Hello,

thanx Alexandre, that's what i was looking for.
So with your suggestion the line looks like this:

/usr/bin/c++   -O3 -DNDEBUG    CMakeFiles/test-TMS.dir/test_TMS.cc.o
CMakeFiles/test-TMS.dir/qa_TMS.cc.o  -o test-TMS -rdynamic
/usr/local/lib64/libgnuradio-core.so -lboost_filesystem-mt
-lboost_system-mt -lcppunit -ldl libgnuradio-TMS.so -lboost_filesystem-mt
-lboost_system-mt /usr/local/lib64/libgruel.so
/usr/local/lib64/libgnuradio-blocks.so /usr/local/lib64/libgnuradio-core.so
-Wl,-rpath,/scr1/work/gnuradio/gr-TMS/build/lib:/usr/local/lib64

part /usr/local/lib64/libgnuradio-blocks.so was added by me and it pased
linking. Before, that part was missing. The mistery is why it was missing.

Nemanja

On Fri, Nov 6, 2015 at 7:43 PM, Alexandre Raymond <
alexandre.j.raym...@gmail.com> 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 <vlasi...@gmail.com> 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 <vlasi...@gmail.com>
> 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 <marcus.muel...@ettus.com
> >
> >> 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 <
> 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ć
> >>>
> >>>
> >>
> >>
> >>
> >> --
> >> Nemanja Savić
> >
> >
> >
> >
> > --
> > Nemanja Savić
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
>



-- 
Nemanja Savić
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to