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