SEO

Greetings all,

I am trying to compile gcc 4.0.1 on AIX 5.3 ML2 with 4.0.1 gcc. I
started with the core and objc only, when that was successful, I
unpacked the c++ code and re-ran configure with only a prefix argument
(as I did the original build). After the Compiler builds and compares
successfully, (and the objc, I assume) it launches into the configure
script for libstdc++-v3, where it fails here:

checking for strtof declaration... yes
checking for strtof... /bin/sh: 684088 Segmentation fault(coredump)
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/home/sg/gcc'
make: *** [bootstrap-lean] Error 2

The core dump was huge, but I was able to compress it down to ~10MB (it
was originally 214MB). I understand that gcc and AIX aren't the best
friends, but any guidance is appreciated. I have tried going back down
to 3.4.3 source in the same manner I said before and get the same results.

I put this out on the gcc help group with no response.

Thank you in advance.

SG

If what you want is gcc for AIX and not necessarily the latest gcc, try
the ports at:-
http://pdslib.seas.ucla.edu/
regards
-kamal

AIX n00b wrote:
> Greetings all,
>
> I am trying to compile gcc 4.0.1 on AIX 5.3 ML2 with 4.0.1 gcc. I
> started with the core and objc only, when that was successful, I
> unpacked the c++ code and re-ran configure with only a prefix argument
> (as I did the original build). After the Compiler builds and compares
> successfully, (and the objc, I assume) it launches into the configure
> script for libstdc++-v3, where it fails here:
>
> checking for strtof declaration... yes
> checking for strtof... /bin/sh: 684088 Segmentation fault(coredump)
> make[1]: *** [configure-target-libstdc++-v3] Error 1
> make[1]: Leaving directory `/home/sg/gcc'
> make: *** [bootstrap-lean] Error 2
>
> The core dump was huge, but I was able to compress it down to ~10MB (it
> was originally 214MB). I understand that gcc and AIX aren't the best
> friends, but any guidance is appreciated. I have tried going back down
> to 3.4.3 source in the same manner I said before and get the same results.
>
> I put this out on the gcc help group with no response.
>
> Thank you in advance.
>
> SG

I know this one - I had the same behaviour with gcc 3.4.4.

when You look at Your system before the configure segfaults, You'll
find
- /tmp being trashed with >5000 files
- CPU load extrem
- the configure script being almost completely paged out.
- the 'checking' getting slower and slower
- almost 100% disk access load

to my understanding it's not a gcc-related problem, but something in
autoconf (which i run a current version of)

yesterdays 'solution' was to rm the first 2000 of those files. (some
time later the build broke anyway)

unless You have a much better understanding of the auto-tools than I
have, try the rm

florian.heigl@gmail.com schrieb:

> I know this one - I had the same behaviour with gcc 3.4.4.
>
> when You look at Your system before the configure segfaults, You'll
> find
> - /tmp being trashed with >5000 files
> - CPU load extrem
> - the configure script being almost completely paged out.
> - the 'checking' getting slower and slower
> - almost 100% disk access load
>
> to my understanding it's not a gcc-related problem, but something in
> autoconf (which i run a current version of)
>
> yesterdays 'solution' was to rm the first 2000 of those files. (some
> time later the build broke anyway)
>
> unless You have a much better understanding of the auto-tools than I
> have, try the rm
>

I have given up with GCC on AIX, but the docs strongly suggests using
"bash" instead of AIX's sh or ksh.
The configure scripts went through in minutes what takes days on my
7009-C20 before (Yes, I know, not really a fast machine).

It later failed the checks of 64bit binaries, even if I configured *not*
to build for anything but power, common and powerpc targets.

--
Uli

florian.heigl@gmail.com wrote:
> I know this one - I had the same behaviour with gcc 3.4.4.
>
> when You look at Your system before the configure segfaults, You'll
> find
> - /tmp being trashed with >5000 files
> - CPU load extrem
> - the configure script being almost completely paged out.
> - the 'checking' getting slower and slower
> - almost 100% disk access load
>
> to my understanding it's not a gcc-related problem, but something in
> autoconf (which i run a current version of)
>
> yesterdays 'solution' was to rm the first 2000 of those files. (some
> time later the build broke anyway)
>
> unless You have a much better understanding of the auto-tools than I
> have, try the rm
>

I got around this problem by making /tmp ramdisk. When I noticed the
configure script for libstdc++-v3 getting slow (right around checking
for nan.h), I ran nmon and noticed that hdisk0 and hdisk1 were getting
flogged. Making /tmp a ramdisk solved that. Even temporarily setting
TMPDIR for gcc to a different area did change that. Only temporary
files diring the compiles when to my TMPDIR area. The configure scripts
remained going to /tmp.

I may get bash and try that. (from other post)

Which version of autoconf is suspect? I don't even thing I have it on
this system.

If worst gets to worst, I may go to precompiled binaries elswhere.

Thanks for all your help.

SG

How did You switch over to bash? is it enough to simply call the
configure from inside a bash?

I definitely want to try this (after the next build break, that is...)

The url is:
http://aixpdslib.seas.ucla.edu/

(and guessing by the file size, g++ is currently missing again.)

two notes:
a) I got a working gcc (that *means* gcc, not g77, not objc, not c++,
not java)
b) switching over to bash didn't help the tmpfiles issue. judging by
the file names, there's been over 3.5 millions created, I now again
deleted some of the older one and now will wait for results

florian.heigl@gmail.com wrote:
> two notes:
> a) I got a working gcc (that *means* gcc, not g77, not objc, not c++,
> not java)
> b) switching over to bash didn't help the tmpfiles issue. judging by
> the file names, there's been over 3.5 millions created, I now again
> deleted some of the older one and now will wait for results
>

Me too, and I actually get a compiled g++ if I "make install" at the
point of failure, but I am sure the c++ compiler I get really does no
good without the libstdc++ library. I made a script to clean out /tmp
after a failure, so my files only get up into the 4000 range.

I'll keep my ear to the ground on this one, and if I come up with
anything, I will be sure to post my findings. I may regress before
3.4.3, to see if I can get a good build, and then go from there. It
isn't like it takes all day to compile. :-)

Thanks again for all of the input!

SG

phewwww!

thank You for the small side note that the make install works, I hadn't
thought of simply trying that out.