Ok... It's my turn to call for help.
After several hours trying to get ./configure running (and succeeding - yay):
Linux version 2.4.21-297-smp4G (root@i386.suse.de) (gcc version 3.3.1 (SuSE Linux)) #1 SMP Sat Jul 23 07:55:00 UTC 2005
When compiling hard_coded_scripts.cpp,
in boost129/boost/python/detail/referent_storage.hpp, line 72:
Internal compiler error: Segmentation
Besides changing GCC versions... any idea?
GCC 3.3.1 is pretty common, I don't think that should be happening.
Besides, I'm not sure I can change the compiler... that's running on the server at work. Using up CPU resources for compiling is one thing... not that they're short on CPU power... but messing with software is another.
PS: I'll post the exact output as soon as I get another chance at building. Configure runs smoothly - no prob at all.
My turn - GCC 3.3.1 - Internal compile error (Panicking)
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
-
- ISO Party Member
- Posts: 453
- Joined: Sat Jul 30, 2005 10:21 am
Try just running 'make' again. That's what I did. You might get more segmentation faults, but they should hopefully occur at different points, and eventually, you'll have a complete build.
You may also consider running "memtest86+" on your system. I had a similar problem (segfaults), and some devs were suggesting it was all about the version of the "boost" library they used. However, I also had a bad section of my RAM, and this caused other failures as well, so I still don't know if all my GCC errors were just the same memory glitch.
You may also consider running "memtest86+" on your system. I had a similar problem (segfaults), and some devs were suggesting it was all about the version of the "boost" library they used. However, I also had a bad section of my RAM, and this caused other failures as well, so I still don't know if all my GCC errors were just the same memory glitch.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
I somehow doubt both.
First, I tried running make many times. The error appeared always at the same spot. Then I tried rewriting that section of code in some other equivalent way (in MSVC, at least, that usually gets around internal compiler errors).
Still, the error stayed at the same place, immune to all my tests.
That also makes me think it's not the memory: after all I did, the outcome should have changed. Anyway, to be really sure about the memory I should do the test: I'll try on Monday (when I power up the server). But that would be very odd as well: all the processes running in it (databases of all kinds, ciphered disk volumes, etc...) run perfectly well 24-7. (well, 24-5 actually).
But there's the other thing: I know many devs (hellcat himself, IIRC) use GCC 3.3 to build, without problems. I'm not sure it's 3.3.1, though. Perhaps there's another subversion.
First, I tried running make many times. The error appeared always at the same spot. Then I tried rewriting that section of code in some other equivalent way (in MSVC, at least, that usually gets around internal compiler errors).
Still, the error stayed at the same place, immune to all my tests.
That also makes me think it's not the memory: after all I did, the outcome should have changed. Anyway, to be really sure about the memory I should do the test: I'll try on Monday (when I power up the server). But that would be very odd as well: all the processes running in it (databases of all kinds, ciphered disk volumes, etc...) run perfectly well 24-7. (well, 24-5 actually).
But there's the other thing: I know many devs (hellcat himself, IIRC) use GCC 3.3 to build, without problems. I'm not sure it's 3.3.1, though. Perhaps there's another subversion.
-
- Lead Network Developer
- Posts: 2560
- Joined: Sun Jan 12, 2003 9:13 am
- Location: Palo Alto CA
- Contact:
You can try compiling the file with problems directly from the command line:
Take the last gcc ... ... ... command that was printed out (usually 3-4 lines or so) and copy it to the prompt (you might want to paste in a text editor to make sure that there are no new-lines in the middle.
Then, try removing optimization flags (-f... and -O2)
or change the -O2 to a -O1
Take the last gcc ... ... ... command that was printed out (usually 3-4 lines or so) and copy it to the prompt (you might want to paste in a text editor to make sure that there are no new-lines in the middle.
Then, try removing optimization flags (-f... and -O2)
or change the -O2 to a -O1
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Ok. I did run the memory test, and it's all ok.
I also did try fiddling with all kind of optimization options, adding and removing things like -O1, -O2, -O3, -O0, -pipe, etc...
The -Ox things moved the error around, but didn't stop it from occurring. The others had no effect. I didn't try running it from the commandline, though. I did all that modifying the Makefile, so I'll have to try that later.
PS: Anyone feeling like replacing boost131 by boost132? I heared it fixes this specific error. What puzzles me, though, is that I've heared others being able to compile under gcc 3.3 *with* boost 131. So I'm feeling a tad jealous.
I also did try fiddling with all kind of optimization options, adding and removing things like -O1, -O2, -O3, -O0, -pipe, etc...
The -Ox things moved the error around, but didn't stop it from occurring. The others had no effect. I didn't try running it from the commandline, though. I did all that modifying the Makefile, so I'll have to try that later.
PS: Anyone feeling like replacing boost131 by boost132? I heared it fixes this specific error. What puzzles me, though, is that I've heared others being able to compile under gcc 3.3 *with* boost 131. So I'm feeling a tad jealous.