------- Comment #2 from oblivian at users dot sourceforge dot net 2008-03-31 13:06 ------- Ok, I've now recompiled about a million times with multiple sets of configure flags and cannot get a stage 1 gcc to compile stage 2 ld correctly. I've got some runs that exhibit the problem of infinite loop and others that just plain segfault based on how the configure flags are set. I've been searching endlessly and the closest thing I can find to the problem I'm running into is bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532. I've used this sysroot approach also to no-avail. In any configuration I try, the host compiler will produce a stage 1 gcc 4.3.0 and ld 2.18 that work as far as compiling a simple hello world app, but in the bootstrap case the gcc 4.3.0 stage 1 creates a hosed ld stage 2.
I have also noticed that most of the methods out there don't bootstrap a compiler so I'm pretty sure this case is way under tested. I'm really starting to think (after starring at the differences between the 4.2.3 and 4.3.0 code bases) that the new libtool implementation in 4.3.0 is the problem. I finally noticed that 4.2.3 still had the old ltcf-c.sh files where as 4.3.0 has them removed. It appears that any attempt to bootstrap a compiler with libraries located in other than /lib or /usr/lib will not create a usable ld executable. Should a bootstrap a compiler methodology no longer be used with 4.3.0 to build a new native system? Any pointers to mailing lists I may have missed for answers would be appreciated as well. I've searched for days with nothing that seems remotely close (except for the bug above, if you can call that close). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35451
