[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7
From: |
Martin Braun |
Subject: |
Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7 |
Date: |
Mon, 6 Jun 2016 10:18:17 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
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>> 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>address@hidden
>> <mailto:address@hidden>> wrote:
>>
>>>
>>>
>>> On Fri, Jun 3, 2016 at 10:19 AM Marcus Müller
>>> <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>
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
- [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Eric Statzer, 2016/06/03
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Marcus Müller, 2016/06/03
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Eric Statzer, 2016/06/03
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Marcus Müller, 2016/06/03
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Martin Braun, 2016/06/03
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Eric Statzer, 2016/06/03
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Richard Bell, 2016/06/04
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Marcus Müller, 2016/06/04
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Richard Bell, 2016/06/04
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7,
Martin Braun <=
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Richard Bell, 2016/06/06
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Martin Braun, 2016/06/06
- Re: [Discuss-gnuradio] [PyBOMBS] pre-2.1.0 release testing on CentOS 7, Martin Braun, 2016/06/03