Re: [Discuss-gnuradio] Issue installing GNU Radio with PyBombs

[Dave NotTelling]

I forced the CMAKE_CXX_COMPILER variable to be c++ and the CMAKE_C_COMPILER
to be cc.  You could likely use the older compiler for UHD by passing in
the compiler, a dash, and the version number.  You should be able to see
all available options by opening a terminal, typing `gcc-` and then hitting
tab twice quickly.  Should autocomplete with all available options.  If
that doesn't work then you can try `dpkg -l | grep gcc`.  If you wanted to
use gcc 4.7, then you could set CMAKE_CXX_COMPILER to g++-4.7.  Should be
able to do something similar with the C compiler and gcc-4.7.  I also found
that installing another more recent version of Boost fixed issues for me.
But, that comes with the issue of keeping two diff versions of Boost on the
same system which can mean lots of odd path variables needing to be set :(

On Tue, Jun 5, 2018 at 7:22 PM, Jose Ruvalcaba  wrote:

> Hi Dave,
>
> I have Ubuntu 16.04. I actually had a similar issue as Jason Matusiak had
> with C++11, as discussed in a recent thread, but I updated my gcc compiler
> from 5.3.2 to 6.4 which seemed to fix the c++11 problem but created this
> new issue. How did you build UHD using gcc, if you don't mind me asking?
>
>
>
> On Tue, Jun 5, 2018 at 2:13 PM, Dave NotTelling 
> wrote:
>
>> I ran into this issue when using clang to build UHD on Ubuntu 16.04.  Had
>> to fall back to using gcc to build UHD due to an issue with 16.04's boost
>> not playing nice with clang.  Not sure if that's what's happening here
>> though.  What OS are you using?  Not sure how PyBombs does things under the
>> covers :(
>>
>> On Tue, Jun 5, 2018 at 2:34 PM Jose Ruvalcaba  wrote:
>>
>>> Hello,
>>>
>>> I am trying to install Gnuradio with PyBombs and I am encountering the
>>> following issue when I reach to the UHD part:
>>>
>>> Cloning into 'uhd'...
>>> remote: Counting objects: 123, done.
>>> remote: Total 123 (delta 23), reused 23 (delta 23), pack-reused 100
>>> Receiving objects: 100% (123/123), 39.75 KiB | 0 bytes/s, done.
>>> Resolving deltas: 100% (79/79), completed with 14 local objects.
>>> Checking connectivity... done.
>>> Configuring: (100%) [=
>>> 
>>> ==]
>>> Building:(100%) [=
>>> 
>>> ==]
>>> [  2%] Built target uhd_rpclib
>>> [ 62%] Built target uhd
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *[ 62%] Linking CXX executable twinrx_freq_hopping../lib/libuhd.so.3.12:
>>> undefined reference to
>>> `boost::re_detail::cpp_regex_traits_implementation::transform_primary[abi:cxx11](char
>>> const*, char const*) const'../lib/libuhd.so.3.12: undefined reference to
>>> `boost::re_detail::cpp_regex_traits_implementation::transform[abi:cxx11](char
>>> const*, char const*) const'collect2: error: ld returned 1 exit
>>> statusexamples/CMakeFiles/twinrx_freq_hopping.dir/build.make:109: recipe
>>> for target 'examples/twinrx_freq_hopping' failedmake[2]: ***
>>> [examples/twinrx_freq_hopping] Error 1CMakeFiles/Makefile2:493: recipe for
>>> target 'examples/CMakeFiles/twinrx_freq_hopping.dir/all' failedmake[1]: ***
>>> [examples/CMakeFiles/twinrx_freq_hopping.dir/all] Error 2Makefile:160:
>>> recipe for target 'all' failedmake: *** [all] Error
>>> 2PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
>>> messages.PyBOMBS.Packager.source - ERROR - Problem occurred while building
>>> package uhd:Build failed.PyBOMBS.install_manager - ERROR - Error installing
>>> package uhd. Aborting.*
>>>
>>>
>>> Can anyone shine some light on what the error may be? Has anyone seen
>>> this issue?
>>>
>>> Thanks,
>>> Jose
>>> ___
>>> 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

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

[Jose Ruvalcaba]

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  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 
>> 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 
>>> 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  for instructions.
 >> make[2]: ***
 >> [lib/CMakeFiles/uhd.dir/usrp/dboard/magnesium/magnesium_radi
 o_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
 >> >>> >> > 

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

[Linda20071]

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 
> 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 
>> 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  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
>>> >> >> >> > 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 

Re: [Discuss-gnuradio] Issue installing GNU Radio with PyBombs

[Jose Ruvalcaba]

Hi Dave,

I have Ubuntu 16.04. I actually had a similar issue as Jason Matusiak had
with C++11, as discussed in a recent thread, but I updated my gcc compiler
from 5.3.2 to 6.4 which seemed to fix the c++11 problem but created this
new issue. How did you build UHD using gcc, if you don't mind me asking?



On Tue, Jun 5, 2018 at 2:13 PM, Dave NotTelling  wrote:

> I ran into this issue when using clang to build UHD on Ubuntu 16.04.  Had
> to fall back to using gcc to build UHD due to an issue with 16.04's boost
> not playing nice with clang.  Not sure if that's what's happening here
> though.  What OS are you using?  Not sure how PyBombs does things under the
> covers :(
>
> On Tue, Jun 5, 2018 at 2:34 PM Jose Ruvalcaba  wrote:
>
>> Hello,
>>
>> I am trying to install Gnuradio with PyBombs and I am encountering the
>> following issue when I reach to the UHD part:
>>
>> Cloning into 'uhd'...
>> remote: Counting objects: 123, done.
>> remote: Total 123 (delta 23), reused 23 (delta 23), pack-reused 100
>> Receiving objects: 100% (123/123), 39.75 KiB | 0 bytes/s, done.
>> Resolving deltas: 100% (79/79), completed with 14 local objects.
>> Checking connectivity... done.
>> Configuring: (100%) [=
>> 
>> ==]
>> Building:(100%) [=
>> 
>> ==]
>> [  2%] Built target uhd_rpclib
>> [ 62%] Built target uhd
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *[ 62%] Linking CXX executable twinrx_freq_hopping../lib/libuhd.so.3.12:
>> undefined reference to
>> `boost::re_detail::cpp_regex_traits_implementation::transform_primary[abi:cxx11](char
>> const*, char const*) const'../lib/libuhd.so.3.12: undefined reference to
>> `boost::re_detail::cpp_regex_traits_implementation::transform[abi:cxx11](char
>> const*, char const*) const'collect2: error: ld returned 1 exit
>> statusexamples/CMakeFiles/twinrx_freq_hopping.dir/build.make:109: recipe
>> for target 'examples/twinrx_freq_hopping' failedmake[2]: ***
>> [examples/twinrx_freq_hopping] Error 1CMakeFiles/Makefile2:493: recipe for
>> target 'examples/CMakeFiles/twinrx_freq_hopping.dir/all' failedmake[1]: ***
>> [examples/CMakeFiles/twinrx_freq_hopping.dir/all] Error 2Makefile:160:
>> recipe for target 'all' failedmake: *** [all] Error
>> 2PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
>> messages.PyBOMBS.Packager.source - ERROR - Problem occurred while building
>> package uhd:Build failed.PyBOMBS.install_manager - ERROR - Error installing
>> package uhd. Aborting.*
>>
>>
>> Can anyone shine some light on what the error may be? Has anyone seen
>> this issue?
>>
>> Thanks,
>> Jose
>> ___
>> 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

Re: [Discuss-gnuradio] Issue installing GNU Radio with PyBombs

[Dave NotTelling]

I ran into this issue when using clang to build UHD on Ubuntu 16.04.  Had
to fall back to using gcc to build UHD due to an issue with 16.04's boost
not playing nice with clang.  Not sure if that's what's happening here
though.  What OS are you using?  Not sure how PyBombs does things under the
covers :(

On Tue, Jun 5, 2018 at 2:34 PM Jose Ruvalcaba  wrote:

> Hello,
>
> I am trying to install Gnuradio with PyBombs and I am encountering the
> following issue when I reach to the UHD part:
>
> Cloning into 'uhd'...
> remote: Counting objects: 123, done.
> remote: Total 123 (delta 23), reused 23 (delta 23), pack-reused 100
> Receiving objects: 100% (123/123), 39.75 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (79/79), completed with 14 local objects.
> Checking connectivity... done.
> Configuring: (100%)
> [===]
> Building:(100%)
> [===]
> [  2%] Built target uhd_rpclib
> [ 62%] Built target uhd
>
>
>
>
>
>
>
>
>
>
>
>
>
> *[ 62%] Linking CXX executable twinrx_freq_hopping../lib/libuhd.so.3.12:
> undefined reference to
> `boost::re_detail::cpp_regex_traits_implementation::transform_primary[abi:cxx11](char
> const*, char const*) const'../lib/libuhd.so.3.12: undefined reference to
> `boost::re_detail::cpp_regex_traits_implementation::transform[abi:cxx11](char
> const*, char const*) const'collect2: error: ld returned 1 exit
> statusexamples/CMakeFiles/twinrx_freq_hopping.dir/build.make:109: recipe
> for target 'examples/twinrx_freq_hopping' failedmake[2]: ***
> [examples/twinrx_freq_hopping] Error 1CMakeFiles/Makefile2:493: recipe for
> target 'examples/CMakeFiles/twinrx_freq_hopping.dir/all' failedmake[1]: ***
> [examples/CMakeFiles/twinrx_freq_hopping.dir/all] Error 2Makefile:160:
> recipe for target 'all' failedmake: *** [all] Error
> 2PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
> messages.PyBOMBS.Packager.source - ERROR - Problem occurred while building
> package uhd:Build failed.PyBOMBS.install_manager - ERROR - Error installing
> package uhd. Aborting.*
>
>
> Can anyone shine some light on what the error may be? Has anyone seen this
> issue?
>
> Thanks,
> Jose
> ___
> 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] Abstract Submission Deadline Extended :: GRCON18 :: Information for Authors & Presenters!

[Humphries, James R.]

Greetings GNU Radio Community,

The deadline for talk, tutorial, and poster abstracts for GRCon2018 has been 
extended to June 30.

The schedule for these submissions is now:

  *   June 30: Abstracts Due (Talks, tutorials, and posters)
  *   July 15: Acceptance Notifications
More information on the submission process can be found here:

https://www.gnuradio.org/grcon-2018/submit/

We look forward to seeing all of the excellent contributions from those working 
in the GNU Radio and software radio world and meeting you all in Henderson soon!

Best Regards,

GRCon2018 Organizers
gr...@gnuradio.org


As a friendly reminder, Early Bird Registration is ending on June 30. 
Registration info can be found here:

https://gnuradio.org/grcon-2018/



___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] functions to generate random signals

[CEL]

Hi!

Linda, you **must not** use rand(). It's not thread-safe, and GNU Radio
is inherently multithreaded. For reference, I've pointed that out in a
recent mail exchange [-1]; the recommendation was the same as Dave's:
use C++11's std:: random generators; that email even has a small code
example :) !

That being said, be warned that this is a lengthy email, and it
presumes you actually care about generating random numbers in detail.

Otherwise you really shouldn't be writing your own code, but follow
Dave's advice, and use the C++11 built in random number generator; the Boost 
library also contains variate generators, i.e. you
can use boost to generate uniform, but also gaussian, laplace, … random
variables.
GNU Radio does export its own random number generators, but let's be
honest: there's zero advantage to using it compared to something that
your language (C++11) brings.

To add something new to what Dave said: If you've got a recent release of GNU 
Radio (3.7.12.0 or later, or current master), then you'll find there's a 
gnuradio-runtime/include/gnuradio/xoroshiro128p.h [0], which
contains a fast, high-quality Pseudorandom number generator; it's usage
is pretty simple:

--
#include
// your other code
uint64_t internal_state[2];
uint64_t seed = 42; /* whatever you want to use as seed */
xoroshiro128p_seed(internal_state, seed);
// all set up for use now!
while(you_need_random_numbers) {
 uint64_t uniform_64bit_int = xoroshiro128p_next(internal_state);
}
--

which gives you uniformly distributed integers on [0;2⁶⁴-1]. Often, you
want floating point uniform numbers instead. Feel free to use these
functions (from [1], LGPL):

--
/*! \brief Convert the uint64_t output of the RNG to a uniform float32
on [0,1]
 */
static inline float uint64_to_f(const uint64_t in) {
  // Float32 has 24 significant bits.
  return (in >> (64-24)) * ( ((float)1.0f) / (UINT64_C(1) << 24));
}

/*! \brief Convert the uint64_t output of the RNG to a uniform double
(float64) on [0,1]
 */
static inline double uint64_to_d(const uint64_t in) {
  // Float64 has 53 significant bits.
  return (in >> (64-53)) * ( ((double)1.0) / (UINT64_C(1) << 53));
}
--

Now, generating Gaussians has traditionally been done with the Box-
Muller transform applied to a uniform variable; for example,
Boost::random does that. I find that this method is /very/ unsatisfactory in 
multiple aspects¹.
Instead, I propose approximating a Gaussian simply by applying the
Central Limit Theorem (CLT) to a sequence of random numbers. I've
tested that – with 32 summands² from the same XOROSHIRO128+ source, you
approximate the theoretical gaussian CDF to a degree much better than
you're likely ever to require. One caveat: The tails of the CDF
disappear, which is logical: by summing up 32 uniforms, you simply
can't get a number larger than 32 times the upper boundary.
My code [1] contains a method for that as well (I recommend using
iterations=32):

--
  /*! \brief Use the Central Limit Theorem to generate a Normal RNG
   */
  static inline float xoroshiro128p_cltf(uint64_t *state, const
uint32_t iterations, const float stddev) {
// expected value of a [0;2^32-1] uniformly discrete variable
// 2^31 - 1/2
static const int32_t mu_32 = (UINT64_C(1) << 31) - 1 ; // +0.5, see
sum -= iterations/2
// variance: ((b-a+1)^2 - 1)/12; b = 2^32 - 1, a = 0
//  =((2^32)^2 -1)  /12
//  =( 2^64 - 1)/12
//  =  2^64 / 12 - 1/12
//  =  2^62 / 3  - 1/12
// close enough
// ~=  2^31 / sqrt(3)
static const float std_32 = 1239850262.2531197f;
float norm = std_32 / stddev * sqrtf(iterations);
int64_t sum;
if(iterations%2) { //odd
  sum = (xoroshiro128p_next(state) >> 32) - mu_32;
} else {
  sum = 0;
}
for(uint32_t i = 0; i < iterations/2; i++) {
  uint64_t tmp = xoroshiro128p_next(state);
  sum +=  (tmp >> 32) - mu_32;
  sum +=  (tmp & 0x) - mu_32;
}
sum += iterations / 2;
float val = (float)sum / norm;
return val;
  }
--

Hope that helps!

Best regards,
Marcus

[-1] http://lists.gnu.org/archive/html/discuss-gnuradio/2018-05/msg0023
7.html
[0] https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/i
nclude/gnuradio/xoroshiro128p.h
[1] https://github.com/marcusmueller/gr-xoroshiro/blob/master/include/x
oroshiro/xoroshiro-variates.h
[2] https://projecteuclid.org/download/pdf_1/euclid.aoms/1177706645
[3] https://github.com/marcusmueller/gr-
xoroshiro/blob/master/examples/Kolmogorov-Smirnov-Test.ipynb

¹ First of all, the code in Boost 

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

[Jason Matusiak]

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  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  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  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
 >> > > 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 

[Discuss-gnuradio] Issue installing GNU Radio with PyBombs

[Jose Ruvalcaba]

Hello,

I am trying to install Gnuradio with PyBombs and I am encountering the
following issue when I reach to the UHD part:

Cloning into 'uhd'...
remote: Counting objects: 123, done.
remote: Total 123 (delta 23), reused 23 (delta 23), pack-reused 100
Receiving objects: 100% (123/123), 39.75 KiB | 0 bytes/s, done.
Resolving deltas: 100% (79/79), completed with 14 local objects.
Checking connectivity... done.
Configuring: (100%)
[===]
Building:(100%)
[===]
[  2%] Built target uhd_rpclib
[ 62%] Built target uhd













*[ 62%] Linking CXX executable twinrx_freq_hopping../lib/libuhd.so.3.12:
undefined reference to
`boost::re_detail::cpp_regex_traits_implementation::transform_primary[abi:cxx11](char
const*, char const*) const'../lib/libuhd.so.3.12: undefined reference to
`boost::re_detail::cpp_regex_traits_implementation::transform[abi:cxx11](char
const*, char const*) const'collect2: error: ld returned 1 exit
statusexamples/CMakeFiles/twinrx_freq_hopping.dir/build.make:109: recipe
for target 'examples/twinrx_freq_hopping' failedmake[2]: ***
[examples/twinrx_freq_hopping] Error 1CMakeFiles/Makefile2:493: recipe for
target 'examples/CMakeFiles/twinrx_freq_hopping.dir/all' failedmake[1]: ***
[examples/CMakeFiles/twinrx_freq_hopping.dir/all] Error 2Makefile:160:
recipe for target 'all' failedmake: *** [all] Error
2PyBOMBS.Packager.source - ERROR - Build failed. See output above for error
messages.PyBOMBS.Packager.source - ERROR - Problem occurred while building
package uhd:Build failed.PyBOMBS.install_manager - ERROR - Error installing
package uhd. Aborting.*


Can anyone shine some light on what the error may be? Has anyone seen this
issue?

Thanks,
Jose
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] A small embedded python block which does frequency peak detect

[CEL]

Hello Ji-yeon,

I think the best way to help you forward here is point out that the
description of the block is very close to actually being an
algorithmical description of what you need to do!
So, maybe you're just missing the tools to build your own blocks and
use the existing blocks; in that case, the GNU Radio guided tutorials
help you very far, as they introduce you to writing Python blocks,
adding tags and using existing blocks.

https://tutorials.gnuradio.org

It's recommendable to read these tutorials in the right order.

Best regards,
Marcus

On Wed, 2018-06-06 at 02:33 +0900, 김지연 wrote:
> Hello,
>  
> Thank you so much for your replying.
> I'm sorry, but could you explain more about a small embedded python
> block which does peak detect and adds tags with the frequency
> information then display using the vector sink?
> Or could you show me a similar example?
> Are there any sites to refer to?
> 
> Best regards,
> Ji-yeon
>  
> -Original Message-
> From: "Derek Kozel" 
> To: "김지연"; 
> Cc: "GNURadio Discussion List"; 
> Sent: 2018-05-28 (월) 20:52:51
> Subject: Re: [Discuss-gnuradio] How can I obtain the frequency value
> from WX GUI FFT Sink block?
>  
> Hello,
>  
> No, there are no automatic peak search markers in the GUI toolkits at
> the moment. It's a frequently requested feature though so we'd be
> eager to merge any implementations into GNU Radio.
>  
> The WX GUI widgets are deprecated and will be removed fairly soon.
> I'd recommend moving over to the QT widgets. For your application it
> would be possible to use the FFT block into a small embedded python
> block which does peak detect and adds tags with the frequency
> information then display using the vector sink.
>  
> Regards, 
> Derek 
> 
> On Mon, May 28, 2018 at 10:15 AM, 김지연  wrote:
> > How can I obtain the frequency value from WX GUI FFT Sink block
> > graph??
> > As in the picture, the frequency that have high power(dB) like
> > 1.39199MHz, 1.57356MHz, 3.26816MHz.
> > Are there other options except moving mouse to that location??? 
> > 
> > ___
> > 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

Re: [Discuss-gnuradio] signal source block to generate sine wave with a initial phase

[Markus Wirsing]

Offset is a DC offset here.
I probably would use a "Skip Head" block to skip the right number of samples to 
get the correct initial phase. Although the setting for that block depends on 
the frequency and the sampling rate.

Or if we're talking about complex values, a "Multiply const" block would work 
too.

Markus

Am 5. Juni 2018 19:31:55 MESZ schrieb Linda20071 :
>Does "offset" used for this purpose? If I want a sine wave with a
>negative
>initial phase of pi/4, should I enter -45 or -(3.14/4) as the value for
>the
>offset?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] functions to generate random signals

[Dave NotTelling]

If you have C++11 or higher you can use
http://en.cppreference.com/w/cpp/numeric/random/uniform_real_distribution.
I think that solves the first problem.  Check out
https://stackoverflow.com/questions/32889309/adding-gaussian-noise for an
example of using it for Gaussian noise.

On Tue, Jun 5, 2018 at 1:19 PM Linda20071  wrote:

> I understand the uniform random generator and Gaussian generator have
> already been implemented in gnuradio. However, For some reason, I need to
> implement some customized blocks to generate my own random sequences.
>
> Could an expert here explain:
> 1. Is there a function in C++ that can generate a uniform noise? Is it the
> function rand() in math.h?
> 2. Is there a function in C++ that can generate a Gaussian noise?
>
> If yes, are there any documents on how to use these two functions?
>
> Thank you.
>
>
>
> ___
> 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] signal source block to generate sine wave with a initial phase

[Linda20071]

Does "offset" used for this purpose? If I want a sine wave with a negative
initial phase of pi/4, should I enter -45 or -(3.14/4) as the value for the
offset?
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] functions to generate random signals

[Linda20071]

I understand the uniform random generator and Gaussian generator have
already been implemented in gnuradio. However, For some reason, I need to
implement some customized blocks to generate my own random sequences.

Could an expert here explain:
1. Is there a function in C++ that can generate a uniform noise? Is it the
function rand() in math.h?
2. Is there a function in C++ that can generate a Gaussian noise?

If yes, are there any documents on how to use these two functions?

Thank you.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[CEL]

Then the answer is really, very likely, to use a container of sorts.
Docker seems to be the choice for that these days.

Best regards,
Marcus

On Tue, 2018-06-05 at 08:08 -0700, Jason Matusiak wrote:
> I wasn't worried about my gnuradio builds as much as my system as a whole 
> when I was mucking with the actually cmake and compilers themselves to try 
> and fix the problem.
> > The whole purpose of using PyBOMBS is to work in PREFIXes, so no need
> > to do that – PyBOMBS does that automatically.

smime.p7s
Description: S/MIME cryptographic signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

[Jason Matusiak]

I wasn't worried about my gnuradio builds as much as my system as a whole when 
I was mucking with the actually cmake and compilers themselves to try and fix 
the problem.
 
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  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  
 > > 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  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
 > > > >>  > > >> > 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 

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  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  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  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
> > > >>  > > >> > 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 

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

[Dave NotTelling]

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  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 
> 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  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
>> >> > >> > 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
>> >> 

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

[Dave NotTelling]

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  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  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
> >>  >> > 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
> 

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

[CEL]

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  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 
> > > >  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 

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

[Philip Balister]

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  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
>>     >     > 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

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

[Jason Matusiak]

So, the host machine performed much better (and of course much faster), so that 
got me past the UHD problem, but I still see the c++11 issue that I was trying 
to solve (I attempted to use Dave's fix.
 
Here is the error I see:
[ 12%] Building CXX object 
gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/float_array_to_int.cc.o
In file included from /usr/local/include/c++/4.9.2/cstdint:35:0,
 from 
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:30:
/usr/local/include/c++/4.9.2/bits/c++0x_warning.h:32:2: error: #error This file 
requires compiler and library support for the ISO C++ 2011 standard. This 
support is currently experimental, and must be enabled with the -std=c++11 or 
-std=gnu++11 compiler options.
 #error This file requires compiler and library support for the \
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:32:14:
 error: 'int64_t' does not name a type
 static const int64_t MAX_INT = INT32_MAX;
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:33:14:
 error: 'int64_t' does not name a type
 static const int64_t MIN_INT = INT32_MIN;
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc: 
In function 'void float_array_to_int(const float*, int*, float, int)':
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:39:5:
 error: 'int64_t' was not declared in this scope
 int64_t r = llrintf(scale * in[i]);
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:40:9:
 error: 'r' was not declared in this scope
 if (r < MIN_INT)
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:40:13:
 error: 'MIN_INT' was not declared in this scope
 if (r < MIN_INT)
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:42:18:
 error: 'MAX_INT' was not declared in this scope
 else if (r > MAX_INT)
 ^
/opt/gnuradio/v3.7.12.0_blah/src/gnuradio/gr-blocks/lib/float_array_to_int.cc:44:31:
 error: 'r' was not declared in this scope
 out[i] = static_cast(r);
 ^
make[2]: *** 
[gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/float_array_to_int.cc.o] Error 1
make[1]: *** [gr-blocks/lib/CMakeFiles/gnuradio-blocks.dir/all] Error 2
make: *** [all] Error 2
 
 
 
 

 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  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 

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

[Jason Matusiak]

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  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  
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

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

[Marcus D. Leech]

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  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
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 
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

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

[Jason Matusiak]

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  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.
 
 
 
 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  
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

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

[Dave NotTelling]

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 
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] install issue with c++11

[Jason Matusiak]

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