discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] install issue with c++11


From: Jason Matusiak
Subject: Re: [Discuss-gnuradio] install issue with c++11
Date: Thu, 07 Jun 2018 07:30:27 -0700
User-agent: MailAPI

OK, here is where everything stands.  I have made some headway, but it is still not 100% solved yet.  I found some misnamed nomenclature in the ettus wiki on how pybombs installs and muddled through some things to get gr-blocks to finish building.  I still cannot get this all to work automagically, but I am hoping someone can see a way, or we can patch pybombs in such a way to make it happen.
 
First - The flag in the config.yml is not "env" like the wiki states, but "setup_env".  This seems to be a sub-setting to the config portion of the config.yml files.  The setup_env flag seems to want to source a file, so what I did was put a path to a file in there that contains my command.  The tail of the config.yml mod looks like this:

- config:
setup_env: /home/me/Downloads/flag

 
My file "flag", contains the one line "export CXXFLAGS=-std=c++11" (minus the quotes of course).
 
So now when the build process starts (via a regular pybombs install), UHD builds fine as always, and gnuradio start fine, then barfs on gr-blocks (the first place that requires ++11).  I know the environment flag took because I see it in one of the commands it is trying to run and fails on (below is an example of one of the failing commands:

[ 27%] Building CXX object gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/max_ss_impl.cc.o
cd /opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gr-blocks/lib && /usr/local/bin/c++ -DENABLE_GR_LOG -DGR_CTRLPORT -DGR_PERFORMANCE_COUNTERS -DHAVE_ARPA_INET_H -DHAVE_BYTESWAP_H -DHAVE_COSF -DHAVE_LINUX_PPDEV_H -DHAVE_LOG4CPP -DHAVE_MALLOC_H -DHAVE_NETDB_H -DHAVE_NETINET_IN_H -DHAVE_SELECT -DHAVE_SIGNAL_H -DHAVE_SINCOS -DHAVE_SINCOSF -DHAVE_SINF -DHAVE_SYS_IPC_H -DHAVE_SYS_MMAN_H -DHAVE_SYS_SELECT_H -DHAVE_SYS_SHM_H -DHAVE_SYS_SOCKET_H -DHAVE_SYS_TIME_H -DHAVE_SYS_TYPES_H -DHAVE_UNISTD_H -Dgnuradio_blocks_EXPORTS -I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gnuradio-runtime/include -I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gnuradio-runtime/include -I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build -I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/volk/include -I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/volk/include -I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gr-blocks/include -I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gr-blocks/lib -I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/include -I/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib -std=c++11 -fvisibility=hidden -Wsign-compare -Wall -Wno-uninitialized -O2 -g -DNDEBUG -fPIC -std=gnu++98 -o CMakeFiles/gnuradio-blocks.dir/max_ss_impl.cc.o -c /opt/gnuradio/v3.7.12.0_blah/src/gnuradio/build/gr-blocks/lib/max_ss_impl.cc

And you can see that it contains "-std=c++11" (that isn't present if I don't do a setup_env in the yml file, so I know pybombs is reading things properly) followed by the normal (for the pybombs install) command "-std=gnu++98" a couple of commands later.  This will fail with the normal complaint about needing ++11.  The interesting thing is, if I do a find and replace, and swap the order of those two flags within all files in src/gnuradio/build/gr-blocks, things build happily.  So what gives?  I can't seem to find a good way to override the ++98.  A workaround is to change the order of those two flags so that the ++11 command comes after it if they are both going to be there, but I can't seem to get that to work either.

Anyone have any ideas?  I don't mind adding additional export commands to my "flag" file, but I haven't found one yet that seems to make a darn to the issue.  I have almost gone as far as I can take it.

 
--------- Original Message ---------
Subject: Re: [Discuss-gnuradio] install issue with c++11
From: "Jose Ruvalcaba" <address@hidden>
Date: 6/5/18 7:44 pm
To: "Linda20071" <address@hidden>

I encountered this issue but seemed to fix it by updating my gcc compiler from 5.4.0 to 6.4. However, after I did this I encountered another problem with the uhd drivers which I opened on a separate thread :( . I got the instructions on how to update the gcc compiler from the following youtube video: https://www.youtube.com/watch?v=vVzshfYSgRk.
Hope this information is of any help.

On Tue, Jun 5, 2018 at 4:27 PM, Linda20071 <address@hidden> wrote:
Is there a good book for an "overview of C++11/14" so somebody with a very good background in c++ can grasp the main idea quickly? Examples in a programming overview book can always help! 
 
Thanks in advance!

On Tue, Jun 5, 2018 at 2:39 PM, Jason Matusiak <address@hidden> wrote:
Does anyone have experience with this?  I am having trouble figuring out if it is not working, or if I am not doing something right.
 
The config.yml looks like this when fresh:

!!omap
- categories:
    hardware:
        forcebuild: true
    common:
        forcebuild: true
- packages:
    gnuradio:
        forcebuild: true
    gqrx:
        forcebuild: true

I then added the line:

- config:
    env:
        export CXXFLAGS:STRING="-std=c++11"

to the end of it.  I don't think that that is the right way to do it, but CXXFLAGS="-std=c++11" didn't work either (no "export" or ":STRING").

Also tried just straight: 

- env
    CXXFLAGS: "-std=c++11"

Any ideas?



Check out https://github.com/gnuradio/pybombs#configuring-a-prefix-environment-eg-for-cross-compiling.  You might be able to set CXXFLAGS with the `--env` flag

On Tue, Jun 5, 2018 at 10:36 AM Dave NotTelling <address@hidden> wrote:
I would suspect that PyBombs doesn't care about your env variables.  That or it overwrites the CMAKE_CXX_FLAGS at some point.  I have no idea how PyBombs builds the CMake projects.  If it's not calling the `cmake` command directly, then it likely will not pick up the env variable.

On Tue, Jun 5, 2018 at 10:33 AM Philip Balister <address@hidden> wrote:
On 06/05/2018 10:06 AM, Marcus D. Leech wrote:
> On 06/05/2018 09:07 AM, Jason Matusiak wrote:
>> Thanks Dave, but that did not seem to work for me.  Here were the
>> commands I ran (slightly different than recommended, but that was for
>> some different recipe mods that have nothing to do with this issue):
>>
>> $ export CXXFLAGS="-std=c++11"
>> $ PREFIX=/opt/gnuradio/v3.7.12.0
>> $ yes | pybombs prefix init $PREFIX
>> $ yes | pybombs -p $PREFIX recipes add gr-recipes
>> git+https://github.com/gnuradio/gr-recipes.git
>> $ source /opt/gnuradio/v3.7.12.0/setup_env.sh
>> $ pybombs -vvv -p $PREFIX install gnuradio
>>
>> And currently things keep erroring out at the same place while
>> installing UHD:
>>
>> [ 43%] Building CXX object
>> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_impl.cpp.o
>>
>> [ 43%] Building CXX object
>> lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o
>>
>> c++: internal compiler error: Killed (program cc1plus)
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <http://bugzilla.redhat.com/bugzilla> for instructions.
>> make[2]: ***
>> [lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radio_ctrl_init.cpp.o]
>> Error 4
>> make[2]: *** Waiting for unfinished jobs....
>>
>> I've also tried env CXXFLAGS=-std=c++11, but it had the same issues.
>>
> That error is internal to the compiler, it is failing to perform its job
> correctly.  This has nothing to do with Gnu Radio, per se, or PyBombs
>   or any of that.  This ordinarily means you compiler is broken in some
> way.
>
> HOWEVER.  How much memory do you have on the system?


Run dmesg and look for messages from the OOM killer (Out of Memory)

Philip

>
> This issue used to happen on systems with small physical memory, because
> compiling certain things requires a lot of virtual memory
>   on the part of the compiler.
>
>
>>
>>     Jason,
>>          You can set the CXXFLAGS env variable to "-std=c++11" and any
>>     CMake builds you run (assuming the same shell) will check the
>>     CXXFLAGS var first.  This assumes that you don't overwrite the
>>     value of CMAKE_CXX_FLAGS.  I just tried it in a terminal with
>>     `export CXXFLAGS="-std=c++11"`, then `cmake ..`, and finally
>>     `VERBOSE=1 make -j 1`.  The verbose make command will show you if
>>     your flags are taking or not.
>>     -Dave
>>
>>     On Tue, Jun 5, 2018 at 8:00 AM Jason Matusiak
>>     <address@hidden
>>     <mailto:address@hidden>> wrote:
>>
>>         I am trying to install gnuradio onto a Centos 7 box and am
>>         having more and more issues with packages that use c++11
>>         commands.  For some of the packages, I add the line:
>>         CMAKE_CXX_FLAGS "-std=c++11"
>>         to the module's CMakeLists.txt file.
>>         The issue is that that requires a fetch, the mod, and then a
>>         rebuild.  This worked OK with it was just gqrx I was doing it
>>         for, but now I need it for other modules it appears, and so I
>>         am trying to find a more elegant solution that covers
>>         everything that is built via a pybombs install gnuradio
>>         command (like gr-blocks, which I can't use this trick for).
>>         If I understand the problem correctly, Ubuntu uses new enough
>>         tools to realize that it needs to use the c++11 version (or
>>         newer I assume) to build since it is needed.  It seems like
>>         even though Centos 7 has the c++11 capability, it does not
>>         smartly trying to use it, and must be directed to for the
>>         installs to work.
>>         Is there something I can do at an upper level to make things
>>         happy on an install?
>>         _______________________________________________
>>         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 mailing list
> 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 mailing list 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 mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

reply via email to

[Prev in Thread] Current Thread [Next in Thread]