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

[CEL]

The whole purpose of using PyBOMBS is to work in PREFIXes, so no need
to do that – PyBOMBS does that automatically.
On Tue, 2018-06-05 at 10:38 -0400, Dave NotTelling wrote:
> 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

smime.p7s
Description: S/MIME cryptographic signature