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" <joruv...@gmail.com> Date: 6/5/18 7:44 pm To: "Linda20071" <linda20...@gmail.com>
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 <linda20...@gmail.com> 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 <ja...@gardettoengineering.com> 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 <dmp250...@gmail.com> 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 <phi...@balister.org> 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 >> <ja...@gardettoengineering.com >> <mailto: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 <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 > > > > > _______________________________________________ > 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 _______________________________________________ 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
