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 <martin.br...@ettus.com > <mailto:martin.br...@ettus.com>> 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: > > > > > rbell@rbell:~/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. > > > > rbell@rbell:~/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 <marcus.muel...@ettus.com > <mailto:marcus.muel...@ettus.com> > > <mailto:marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>> > 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:eric.stat...@gmail.com > <mailto:eric.stat...@gmail.com>>eric.stat...@gmail.com > <mailto:eric.stat...@gmail.com> > >> <mailto:eric.stat...@gmail.com <mailto:eric.stat...@gmail.com>>> > wrote: > >> > >>> > >>> > >>> On Fri, Jun 3, 2016 at 10:19 AM Marcus Müller > >>> <marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com> > <mailto:marcus.muel...@ettus.com <mailto:marcus.muel...@ettus.com>>> > 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 > >>> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > <mailto:Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>> > >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
