# Follow up: Failure to build GNU Radio on various Ubuntu builds

**URL:** <https://www.ruby-forum.com/t/follow-up-failure-to-build-gnu-radio-on-various-ubuntu-builds/243057>\
**Category:** GNU Radio\
**Created:** [August 18, 2015, 5:16pm UTC](https://www.ruby-forum.com/t/follow-up-failure-to-build-gnu-radio-on-various-ubuntu-builds/243057 "2015-08-18T17:16:51Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sadaf\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/858c86/32.png) [@Sadaf\_N](https://www.ruby-forum.com/u/Sadaf_N)\
**Post date:** [August 18, 2015, 5:16pm UTC](https://www.ruby-forum.com/t/follow-up-failure-to-build-gnu-radio-on-various-ubuntu-builds/243057/1 "2015-08-18T17:16:51Z")

</div>

I managed to resolve a problem with the install.

Commands, find\_usrp\_devices and uhd\_usrp\_probe failed to get my B100 to  
respond with the model and daughter board and FPGA information. Yet at  
other  
times it would work, albeit very briefly.

Whilst trying to keep this follow up mail brief, the problem was caused  
by  
the USB lead I was using. Although a new lead and just 2m in length, it  
must  
be unable to handle the bus communications between the USRP and my PC.  
However, for the past few months it’s been fine when using my B100 on  
Windows 8.1 when casually running SDR# or HDSDR.

Whilst working in Ubuntu, when I ran the lsusb command, the USRP was  
listed.  
This was puzzling, for me anyway, as beyond that the USRP would not  
function  
or rather I could not get it to intermittently communicate with my PC,  
as  
mentioned above.

Whilst switching back to my Windows partition, I checked the USB lead  
with  
known working applications in Windows 10; HDSDR and SDR#, since by this  
time  
I felt my USRP B100 may have been faulty. My USRP wouldn’t work in those  
applications either, though it had previously worked perfectly well on  
the  
same now suspect USB lead. The commands, find\_usrp\_devices and  
uhd\_usrp\_probe on a Windows platform (from Command line) wouldn’t work  
with  
the suspect faulty cable attached (the command, uhd\_usrp\_probe,being  
particularly problematic in returning runtime errors).

Again, without going into more tests and irregular driver responses in  
Windows 10, with the UHD driver throwing up errors, I changed the USB  
cable  
with another cable in desperation and the whole system came alive and  
has  
remained so over the past day or so.

I swapped the cable with a 1.5m filtered USB cable I’ve owned for years  
and  
this confirmed the problem. I swapped it back again, to the suspect  
cable,  
and the irregular functions reoccurred. However, the suspect USB lead  
works  
fine with any other equipment I have such as printer and an USB  
expansion  
port. I wasn’t using an expansion USB device when these errors were  
occurring BTW, just the suspect one USB lead between the PC and the USRP  
B100.

All it is left for me to do is now go back to my Ubuntu partition and  
try to  
reinstall GNURadio again on a fresh install of Ubuntu (as I have done so  
many times this past week trying to get it to work) and hopefully get  
some  
more positive results.

I will start with Ubuntu 12.04 LTS 64 bit as that was the last known  
Ubuntu  
distro that worked two years ago when running many successful installs  
of  
GNURadio on my other PC’s and laptop. This includes successfully  
installing  
GNURadio on Windows 7 at the time. However, in terms of Ubuntu, I will  
again  
use Marcus’s excellent build-gnuradio script, as I did two years ago and  
work on from there. I’m hoping Marcus’s script will fetch the required  
dependencies and build to a successful outcome this time around again.

Else, if you can advise on any other approach to installing GNURadio, on  
more recent Ubuntu distro’s, so that it will also reliably work with my  
B100  
USRP, I should be grateful again for your help. I really want to learn  
and  
work with GNURadio so that I can better understand its function since  
with  
various academic commitments I have had so little time over the past  
couple  
of years and more since investing in the Ettus USRP concept back in  
2012.

Again, your patient help is very much appreciated.

Mark

---

<div class="post-metadata">

**Author:** ![markh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7993a0/32.png) [@markh](https://www.ruby-forum.com/u/markh)\
**Post date:** [August 18, 2015, 5:16pm UTC](https://www.ruby-forum.com/t/follow-up-failure-to-build-gnu-radio-on-various-ubuntu-builds/243057/2 "2015-08-18T17:16:52Z")

</div>

I have had similar problems with cheap USB cables that work for  
low-speed devices, but utterly fail for higher-speed transfers.

You might as well update to at least Ubuntu 14.04 or even 15.04, Gnu  
Radio (via build-gnuradio) is known to work in that environment.

---

<div class="post-metadata">

**Author:** ![markh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7993a0/32.png) [@markh](https://www.ruby-forum.com/u/markh)\
**Post date:** [August 21, 2015, 10:39am UTC](https://www.ruby-forum.com/t/follow-up-failure-to-build-gnu-radio-on-various-ubuntu-builds/243057/3 "2015-08-21T10:39:46Z")

</div>

Hi,

as Marcus L. said, the logs are tremendously informative. A segfault in  
the cc1plus executable (which is the actual C++ compiler in GCC) is  
extremely seldom, and should be treated as either a bug in GCC, or a bug  
in your system.  
Now, I haven’t seen an Out-Of-Memory error in a while, since RAM has  
become too cheap :), but I think OOM-killing wouldn’t say “Segmentation  
fault”. Trying to access a larger-than 2^32 address in a 32bit system  
might, though.  
So either you’re running a 32 bit OS, and the compiler needs more than  
2GB of RAM, or I guess you have a GCC bug at hand, or something like  
defective RAM – I noticed defective RAM in my previous machine only  
when I tried to work with an 8GB file in RAM, because the probability of  
something going wrong scales with the amount of RAM your system actually  
uses.

Best regards,  
Marcus

---

<div class="post-metadata">

**Author:** ![markh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7993a0/32.png) [@markh](https://www.ruby-forum.com/u/markh)\
**Post date:** [August 21, 2015, 6:38pm UTC](https://www.ruby-forum.com/t/follow-up-failure-to-build-gnu-radio-on-various-ubuntu-builds/243057/4 "2015-08-21T18:38:48Z")

</div>

On 08/20/2015 03:13 PM, Mark wrote:

> 

Hmmm, if you have 4GB of RAM, that should be plenty. Is this a physical  
machine, or a VM?

The only time I’ve seen GCC segfault is due to out-of-memory. But my  
experience is that 4GB of physical RAM is enough–I’ve rebuilt GR and  
UHD on  
my Fedora-20 machine with only 4GB of memory on it several times in  
the last couple of weeks without issue.

What does:

dpkg-query -l gcc

Return?

---

<div class="post-metadata">

**Author:** ![markh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7993a0/32.png) [@markh](https://www.ruby-forum.com/u/markh)\
**Post date:** [August 21, 2015, 10:14am UTC](https://www.ruby-forum.com/t/follow-up-failure-to-build-gnu-radio-on-various-ubuntu-builds/243057/5 "2015-08-21T10:14:39Z")

</div>

On 08/20/2015 09:33 AM, Mark wrote:

> Here is another error.
> 
> The errors are many and I could keep posting variations of these to you and I’m  
> not sure what purpose they would serve in finding a solution.
> 
> Anyway, I will post this error and await your advice before trying again. The  
> next attempt will be around the 30th attempt to get GNURadio to install  
> successfully.  
> Again, when the compiler segfaults, that’s something that’s entirely  
> outside the scope of what build-gnuradio can cope with, and isn’t an  
> issue with  
> Gnu Radio, per se. This usually happens due, as I said in my  
> few-minutes-ago response, to insufficient system RAM.

This is the first time I’ve seen logs from you that contain obvious  
compiler internal errors, which is why it wasn’t obvious, before,  
exactly what  
was going on. So, getting these detailed logs is tremendously useful  
in figuring out what is going on.

---

<div class="post-metadata">

**Author:** ![markh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7993a0/32.png) [@markh](https://www.ruby-forum.com/u/markh)\
**Post date:** [August 21, 2015, 7:55pm UTC](https://www.ruby-forum.com/t/follow-up-failure-to-build-gnu-radio-on-various-ubuntu-builds/243057/6 "2015-08-21T19:55:20Z")

</div>

On 08/20/2015 04:01 PM, Mark wrote:

> To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid), “[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)”  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

When you do one of these builds, and it fails due to segfault, is there  
anything suggestive showing up in ‘dmesg’ ??

This just looks really weird. There are _hundreds_ of people around the  
world who have built GR from source on Ubuntu 14.04 without issue.

Are all you packages up-to-date after you did the install?

---

<div class="post-metadata">

**Author:** ![markh](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7993a0/32.png) [@markh](https://www.ruby-forum.com/u/markh)\
**Post date:** [August 21, 2015, 7:44pm UTC](https://www.ruby-forum.com/t/follow-up-failure-to-build-gnu-radio-on-various-ubuntu-builds/243057/7 "2015-08-21T19:44:49Z")

</div>

On 08/20/2015 06:13 AM, Mark wrote:

> Please submit a full bug report,
> 
> If you can continue to advise I should be grateful.
> 
> Mark  
> This is almost certainly a known problem in the compiler when it runs  
> out of memory–how much memory do you have on your machine?

This error is coming from the compiler, so there’s nothing that  
build-gnuradio can do about it, however, you can:

(1) Install more RAM  
(2) Add a secondary swap file. See, for example:

> **[How To Add Swap on Ubuntu 14.04 | DigitalOcean](https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04)**
>
> Swap space can be used as an “overflow” area for your system when you run out of RAM. The operating system can store data that would normally be kept in RAM…
