rockboxdev.sh gcc/combine.c error

[crowd345]

Hello to everybody who care enough to read this topic!

I'm new here, so i am not sure is this right part of forum to ask such question or not. I hope so.

I followed this instruction The Simple Guide To Compiling In Linux with my home Ubuntu 10.10, and couple times with VirtualBoxed one (same version of Ubuntu, but it was preinstalled and i downloaded it from http://downloads.sourceforge.net/virtualboximage/ubuntu-xxx.vdi.bz2).

I believe i take steps exactly how it stated in manual, but after i launch in terminal command:

Code: [Select]

sudo ./rockboxdev.sh

i can see lots of work that my PC is doing. But after probably 30 mins it stops and give me this information:

Code: [Select]

    I../../gcc-4.4.4/gcc/../libdecnumber -I../../gcc-4.4.4/gcc/../libdecnumber/dpd -I../libdecnumber    ../../gcc-4.4.4/gcc/combine.c -o combine.o
    ../../gcc-4.4.4/gcc/combine.c: In function 'make_extraction':
    ../../gcc-4.4.4/gcc/combine.c:6776: internal compiler error: Segmentation fault
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions.
    make[2]: *** [combine.o] Error 1
    make[2]: Leaving directory `/tmp/rbdev-build/build-gcc/gcc'
    make[1]: *** [all-gcc] Error 2
    make[1]: Leaving directory `/tmp/rbdev-build/build-gcc'
    make: *** [all] Error 2
    ubuntu@ubuntu-VirtualBox:~/rockbox/tools$

Please suggest something that can fix this bug. Thanks!

P.S. target arch is "e - arm-eabi - ipod"

[AlexP]

For target arch you just type "e", not the rest of the line but I don't think that should have caused this.

To clarify, you are running this in a ubuntu 10.10 VM?

[crowd345]

For target arch you just type "e", not the rest of the line but I don't think that should have caused this.

No, that's just misunderstanding. Actually i taped it correct ("e"), but thought to give a little more information about it. Never mind..
 

To clarify, you are running this in a ubuntu 10.10 VM?

Well, yes. And as i stated in previous post i also tried it on my real home Ubuntu 10.10 and got stocked with same error message.

After it i can try to use "../tools/configure" command and it will give me that (I believe my "$PATH" parameter is correct just proper compiler doesn't installed):

Code: [Select]

21
Platform set to ipodnano1g
Build (N)ormal, (A)dvanced, (S)imulator, (B)ootloader, (C)heckWPS, (D)atabase tool, (M)anual: (Defaults to N)
n
Normal build selected
Using source code root directory: /home/maxim/rockbox
../tools/configure: 3041: arm-elf-eabi-gcc: not found
[WARNING] The compiler you must use (arm-elf-eabi-gcc) is not in your path!
[WARNING] this may cause your build to fail since we cannot do the
[WARNING] checks we want now.
Using arm-elf-eabi-ld 2.20.1.20100303
Created Makefile
maxim@m-desktop:~/rockbox/build$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
maxim@m-desktop:~/rockbox/build$ 

Post Merge: January 30, 2011, 10:28:30 AMI believe there should be many people using 10.10. Is anybody from you faced such problem or that's just me?

[torne]

If you try doing it again, does it fail at the same place, or a different file during the build? If it's random places then the most common cause is flaky hardware (bad RAM is common). If it's consistent then something is probably wrong with the VM...

[crowd345]

You guys undermine my confidence in English skills  
(i'm not a native speaker and you are probably already noticed that)

If you try doing it again, does it fail at the same place, or a different file during the build?

"i also tried it on my real home Ubuntu 10.10 and got stocked with same error message."

In summary i tried it one time with my real system and probably 3 times with clean brand new VirtualBoxed one (That was downloaded from sourceforge.net). That's always 100% same error in same module.

If it's consistent then something is probably wrong with the VM...

Well, that doesn't explain why this error also affected my real Ubuntu system (not VM).

Could it possibly be a problem with .sh script? Because i have up to date pretty "out of the box" OS with minor changes. Please tell me if you are sure there nothing wrong with script when i'll just try VMWare Image or some another way. Thank you for your help!

[torne]

Sorry, it's not your english skills but my lack of thorough reading of your post.

The rockboxdev.sh script just calls gcc's build process, it doesn't do anything itself. If the gcc build fails on the same file every time, even on a VM, then there's a problem, but it's not one anyone else has using the same source.

The command you gave is not complete, it's missing the beginning (most of the invocations of gcc during the build are 10+ lines long) so I can't see whether it's running the host compiler or the stage1/stage2 compiler. if it's the former then it's probably an issue with the version of gcc in your Ubuntu version.. if the latter then something strange is going on because that's the binary built by earlier stages of the gcc build which should be relatively consistent with what everyone else gets

[gbl08ma]

I'm running Ubuntu 10.10 (upgraded from 10.04 without formatting) and last time I ran tools/configure.sh I had no problems.

Obviously, something might have changed in the SVN in the meantime that might have caused that. But as torne says, it might be the specific gcc instalation.

[torne]

When was the last time? We change gcc version from time to time, so rockboxdev.sh is not always building the same thing.

[gbl08ma]

About a month and a half ago. The gcc package on the Ubuntu repositories or the tools/rockboxdev.sh could have changed in this time...

[crowd345]

Well, i finally figured it out 

After my last message I tried Ubuntu 9.10 VM and manual installation of different versions of GCC and all that fail but with errors in different modules.  So i tested my RAM with memtest (from Ubuntu's bootloader) and it's looked ok. After that i loaded "fail safe" options in BIOS and rockboxdev.sh worked out for me  just fine.

So torne was right- it's the flaky hardware in my situation, but that's still a little bit mystery for me. Thanks for assistance!

[torne]

gcc spends all its time manipulating vast numbers of pointers; it's somewhat more likely to be affected by hardware flakiness than most software