Hi Jason, to not hose my system every day, I simply work in prefixes. Basically, find my shell's RC file below. With options like `- DCMAKE_INSTALL_PREFIX=$GRPREFIX` (for CMake) or `export`ing PREFIX=$GRPREFIX (before running ./configure scripts) one can set the installation directory so that things end up in the right place.
At times, I just paste my build instructions into a Dockerfile, or I
clone a bare CentOS/Fedora/Ubuntu Docker container and do my stuff
there. While not giving the isolation that a proper VM would give, this
still is a pretty safe bet.
Cheers,
Marcus
#.zshenv for multiple GNU Radio installations
GRPREFIX=/home/marcus/.usrlocal
export EDITOR="/usr/bin/vim"
if [[ -z $( echo $PATH | grep $GRPREFIX ) ]] {
export PATH=$PATH:~/bin:$GRPREFIX/bin
export PATH=$PATH:$GRPREFIX/lib64/uhd/examples
export LD_LOAD_LIBRARY=$LD_LOAD_LIBRARY:$GRPREFIX/lib64
export LD_LOAD_LIBRARY=$LD_LOAD_LIBRARY:$GRPREFIX/lib
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GRPREFIX/lib64
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GRPREFIX/lib
export PYTHONPATH=$PYTHONPATH:$GRPREFIX/lib64/python2.7/dist-
packages
export PYTHONPATH=$PYTHONPATH:$GRPREFIX/lib64/python2.7/site-
packages
export
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$GRPREFIX/lib64/pkgconfig
}
On Tue, 2018-06-05 at 07:17 -0700, Jason Matusiak wrote:
> Marcus, I started to suspect after the thread started that that was the case.
> I was doing this work in a VM so as to not hose my host system too much, but
> I just started another install on my host system to do the work without
> memory being an issue.
>
> That said, the c++11 concerns are definitely there, and the new change to
> gr-blocks that was committed about 7 days ago was when we decided we need to
> come up with a good solution since I couldn't simply fetch/mod/rebuild that
> as easy as I could gqrx.
>
> Fingers crossed that Dave's advice works on my beefier setup (sadly, one of
> my 100 other attempts might have worked, I don't recall when this memory
> issue started cropping up after I took on the c++11 task, but it wasn't there
> the other day).
>
> >
> > 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?
> >
> > 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
> > > > <ja...@gardettoengineering.com> 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
> > > > > 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
> >
> > _______________________________________________ Discuss-gnuradio mailing
> > list 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
