Re: [Discuss-gnuradio] Follow up: Failure to build GNU Radio on various Ubuntu builds
On 08/20/2015 03:13 PM, Mark wrote: Apologies, I didn’t see this at the foot of your Email. I will study it later tonight or at the weekend. Many grateful thanks again. (2) Add a secondary swap file. See, for example: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04 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? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Follow up: Failure to build GNU Radio on various Ubuntu builds
On 08/20/2015 06:13 AM, Mark wrote: OK, I changed the distro to Ubuntu 14.04.3 LTS 64Bit and followed your advice to simply issue the command "wget http://www.sbrac.org/files/build-gnuradio && chmod a+x ./build-gnuradio && ./build-gnuradio --verbose" and I find myself right back where I started last week and that is the constant failure to build past this point . . . === [ 24%] Building CXX object lib/CMakeFiles/uhd.dir/transport/nirio/rpc/usrprio_rpc_client.cpp.o /home/mark/uhd/host/lib/transport/nirio/rpc/usrprio_rpc_client.cpp:1:0: internal compiler error: Segmentation fault // ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. The bug is not reproducible, so it is likely a hardware or OS problem. make[2]: *** [lib/CMakeFiles/uhd.dir/transport/nirio/rpc/usrprio_rpc_client.cpp.o] Error 1 make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2 make: *** [all] Error 2 UHD build apparently failed Exiting UHD build = 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: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Follow up: Failure to build GNU Radio on various Ubuntu builds
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.
[ 35%] Built target blocks_swig3_gr_blocks_swig_a6e57
Scanning dependencies of target _blocks_swig3
[ 35%] Building CXX object
gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o
/home/mark/gnuradio/build/gr-blocks/swig/blocks_swig3PYTHON_wrap.cxx: In
function ‘PyObject* _wrap_float_to_char_sptr_min_noutput_items(PyObject*,
PyObject*)’:
/home/mark/gnuradio/build/gr-blocks/swig/blocks_swig3PYTHON_wrap.cxx:12199:22:
internal compiler error: Segmentation fault
SWIGINTERN PyObject *_wrap_float_to_char_sptr_min_noutput_items(PyObject
*SWIGUNUSEDPARM(self), PyObject *args) {
^
c++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
Error 4
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error 2
make: *** [all] Error 2
make failed
Exiting Gnu Radio build/install
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Follow up: Failure to build GNU Radio on various Ubuntu builds
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
On 20.08.2015 17:11, Marcus D. Leech wrote:
> 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.
>
>
>>
>>
>>
>>
>>
>> [ 35%] Built target blocks_swig3_gr_blocks_swig_a6e57
>> Scanning dependencies of target _blocks_swig3
>> [ 35%] Building CXX object
>> gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o
>> /home/mark/gnuradio/build/gr-blocks/swig/blocks_swig3PYTHON_wrap.cxx:
>> In function ‘PyObject*
>> _wrap_float_to_char_sptr_min_noutput_items(PyObject*, PyObject*)’:
>> /home/mark/gnuradio/build/gr-blocks/swig/blocks_swig3PYTHON_wrap.cxx:12199:22:
>> internal compiler error: Segmentation fault
>> SWIGINTERN PyObject
>> *_wrap_float_to_char_sptr_min_noutput_items(PyObject
>> *SWIGUNUSEDPARM(self), PyObject *args) {
>>^
>> c++: internal compiler error: Segmentation fault (program cc1plus)
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See for instructions.
>> make[2]: ***
>> [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
>> Error 4
>> make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error 2
>> make: *** [all] Error 2
>> make failed
>> Exiting Gnu Radio build/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] Follow up: Failure to build GNU Radio on various Ubuntu builds
On 08/20/2015 04:01 PM, Mark wrote: mark@myGNURadioPC:~$ dpkg-query -l gcc Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==---= ii gcc4:4.8.2-1ubu amd64GNU C compiler mark@myGNURadioPC:~$ sudo swapon -s [sudo] password for mark: FilenameTypeSizeUsedPriority /dev/sda5 partition 7811516 0 -1 mark@myGNURadioPC:~$ free -m total used free sharedbuffers cached Mem: 3680 1536 2144380 38863 -/+ buffers/cache:634 3046 Swap: 7628 0 7628 On Thu, 20/8/15, Marcus D. Leech wrote: Subject: Re: Follow up: Failure to build GNU Radio on various Ubuntu builds To: mark.hopew...@btinternet.com, "Discuss-gnuradio@gnu.org" Date: Thursday, 20 August, 2015, 20:19 What does: dpkg-query -l gcc Return? 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? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Follow up: Failure to build GNU Radio on various Ubuntu builds
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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Follow up: Failure to build GNU Radio on various Ubuntu builds
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. On 2015-08-18 10:42, Mark wrote: > 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
