Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7

[Martin Braun]

You could also add your oot to the inventory file, add a recipe file,
and then use pybombs to compile your OOT to check if it's an env or
setup issue.

M

On 06/06/2016 11:08 AM, Richard Bell wrote:
> Hi Martin,
> 
> Yes I did source the setup_env.sh file. I can call gnuradio-companion
> from command line and the base install works fine. It's only when
> compiling OOT modules that I have issues.
> 
>  I have not tried compiling without sudo, I will give it a shot.
> 
> Rich
> 
> On Mon, Jun 6, 2016 at 10:18 AM, Martin Braun <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Richard,
> 
>     did you call your setup_env.sh before doing the compile? Also, you can
>     run cmake with -Wno-dev to remove some more annoying warnings.
> 
>     On 06/04/2016 04:40 PM, Richard Bell wrote:
>     > Sure no problem. Here is the output when I try to build a brand new or
>     > pre-existing OOT module, notice the cmake warnings:
>     >
>     > 
> address@hidden:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>     > cmake -DCMAKE_INSTALL_PREFIX=/home/rbell/Documents/grprefix/ ..
>     > -- The CXX compiler identification is GNU 5.3.1
>     > [...]
>     > -- Configuring done
>     > -- Generating done
>     > -- Build files have been written to:
>     > 
> /home/rbell/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build
> 
>     Looks like this worked fine.
> 
>     > 
> address@hidden:~/Documents/pcodes/radio_devel/custom_grblocks/gr-add_tagged_stream_once/build$
>     > sudo make install
> 
>     You really don't want to 'sudo make' anything unless you really need to.
>     Here, you don't, as far as I can tell.
> 
>     Martin
> 
>     > Scanning dependencies of target gnuradio-add_tagged_stream_once
>     > [  4%] Building CXX object
>     > 
> lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/add_tagged_stream_once_impl.cc.o
>     > [  8%] Linking CXX shared library libgnuradio-add_tagged_stream_once.so
>     > /usr/bin/ld: cannot find -lgnuradio-runtime
>     > /usr/bin/ld: cannot find -lgnuradio-pmt
>     > collect2: error: ld returned 1 exit status
>     > lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/build.make:98: recipe
>     > for target 'lib/libgnuradio-add_tagged_stream_once.so' failed
>     > make[2]: *** [lib/libgnuradio-add_tagged_stream_once.so] Error 1
>     > CMakeFiles/Makefile2:137: recipe for target
>     > 'lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/all' failed
>     > make[1]: *** [lib/CMakeFiles/gnuradio-add_tagged_stream_once.dir/all]
>     > Error 2
>     > Makefile:138: recipe for target 'all' failed
>     > make: *** [all] Error 2
>     >
>     > On Sat, Jun 4, 2016 at 9:14 AM, Marcus Müller <address@hidden 
> <mailto:address@hidden>
>     > <mailto:address@hidden <mailto:address@hidden>>> wrote:
>     >
>     >     Hi Rich,
>     >
>     >     currently unable to access my Ubuntu VMs; could you copy&paste the
>     >     build log of your OOT? Also, I might be a bit paranoid, but could
>     >     you verify by "which gr_modtool" that you're really running the
>     >     modtool you want?
>     >
>     >     Best regards,
>     >     Marcus
>     >
>     >
>     >     On 04.06.2016 17:51, Richard Bell wrote:
>     >>     Since I didn't get much feedback when I brought this up a few
>     >>     weeks ago, I want to bring it up again to make sure you all see
>     >>     it.  After using the default pybombs command to build a clean
>     >>     install on Ubuntu 16.04, everything worked fine except that I
>     >>     can't get gr_modtool working. No OOT Modules I make, old or brand
>     >>     new, will make it through compile. There are cmake issues I've
>     >>     never seen before.
>     >>
>     >>     Can someone confirm they have used gr_modtool on Ubuntu 16.04
>     >>     successfully after installing via the pybombs default route.
>     >>
>     >>     Sent from my iPad
>     >>
>     >>     On Jun 3, 2016, at 7:42 PM, Eric Statzer
>     >>     <<mailto:address@hidden
>     <mailto:address@hidden>>address@hidden
>     <mailto:address@hidden>
>     >>     <mailto:address@hidden <mailto:address@hidden>>> wrote:
>     >>
>     >>>
>     >>>
>     >>>     On Fri, Jun 3, 2016 at 10:19 AM Marcus Müller
>     >>>     <address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>>
>     wrote:
>     >>>
>     >>>>         Everyone should get a kick out of this: I had fixed this
>     >>>>         once before [1] but it was actually YOU, Marcus, that broke
>     >>>>         it again! [2]
>     >>>         I wish that was true! First of all, we need to find a better
>     >>>         way to fix that then to build libtool on practically all
>     >>>         platforms from source.
>     >>>         You really don't need libtool > 2.4.6 to build thrift. Works
>     >>>         perfectly on my Fedora 22 with libtool 2.4.2 .
>     >>>         The problem is not the libtool version, by the way.
>     >>>         autoconf/aclocal just can't, for some reasons I really can't
>     >>>         figure out, find the "default" system-wide M4 files
>     >>>         containing the PKG_CHECK_MODULES macro under specific
>     >>>         circumstances. It seems that installing libtool into the
>     same
>     >>>         prefix one is going to use later on fixes the problem
>     (as the
>     >>>         M4s end up in a location that aclocal ends up looking in).
>     >>>         Have a test: if you edit the bootstrap.sh of thrift, and
>     >>>         modify the
>     >>>
>     >>>         aclocal -I ./aclocal
>     >>>
>     >>>         line to
>     >>>
>     >>>         aclocal -I $(env -i aclocal --print-ac-dir) -I ./aclocal
>     >>>
>     >>>         the M4 syntax error disappears, at least for me. Of course,
>     >>>         thrift wouldn't successfully build with those modifications,
>     >>>         either, but that's really a long rabbit hole to go into :)
>     >>>         Hence my curiosity!
>     >>>
>     >>>
>     >>>     Alright, its all coming back to me now, I think you've got me
>     >>>     straightened out again, Marcus.  I was definitely wrong on the
>     >>>     pkg-config/libtool versions before, thanks for taking my hasty
>     >>>     accusations so well!  This is the exact same sort of issue
>     that I
>     >>>     was running in to when running autoreconf for libosmo-dsp and I
>     >>>     realized that having ANY version of pkg-config installed from
>     >>>     source under the PYBOMBS_PREFIX would make these sort of errors
>     >>>     go away, too.  I'm on-board with leaving the pkg-config and
>     >>>     libtool versions alone and fixing the real underlying problems.
>     >>>
>     >>>     So, the thrift recipe was switched to using git for the source
>     >>>     fetch around this time [3] due to a possible thrift bug.
>     >>>     Question: now that thrift 0.9.3 is available in tarball form,
>     >>>     might we want to switch back to using the release tarball?  The
>     >>>     benefit of the tarball is that it already includes all of the
>     >>>     required m4 macro files, and that makes ./configure run MUCH
>     more
>     >>>     smoothly.  In fact, this branch [4], which just switches to the
>     >>>     tarball release of thrift 0.9.3, builds cleanly for me on CentOS
>     >>>     7.  Give it a shot!
>     >>>
>     >>>     -Eric
>     >>>
>     >>>     [3]
>     
> https://github.com/gnuradio/gnuradio/commit/621c086b94e1f9b70f24034bf6fb6f7e15e5fa7c
>     >>>     [4] https://github.com/estatz/gr-recipes/tree/thrift_tarball
>     >>>     _______________________________________________
>     >>>     Discuss-gnuradio mailing list
>     >>>     address@hidden <mailto:address@hidden>
>     <mailto:address@hidden <mailto:address@hidden>>
>     >>>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Discuss-gnuradio mailing list
>     > address@hidden <mailto:address@hidden>
>     > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     >
> 
> 
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>