------- Comment #1 from oblivian at users dot sourceforge dot net 2008-03-25 04:05 ------- I've started over using the 4.3.0 release source files instead of svn and still have the same problem.
After more checking I've narrowed this down to stage 2 ld-new, collect2 and the xgcc from stage 1. The do_spec_1 routine shows argbuf getting loaded with the path to ./prev-gcc/xgcc instead of a -L./prev-gcc/ linker directory. This causes collect2 or the executor (I'm still not clear on the run path) to run xgcc again which loads with the wrong argbuf again and calls collect2 again and so on until it eats all memory obviously. If I copy the ld-new from prev-ld to the stage2 ld directory the stage2 compiler will run and inserts -L./prev-gcc ok. I'm still trying to track down if this is a binutils ld problem or if binutils is broken by 4.3.0. I know first indication is that ld and therefore binutils is broken, but as I said before the exact same setup with 4.2.3 works fine. Also, I've now tried the compile setup I stated before, except on a gcc 4.2.3, binutils 2.18 and glibc 2.7 system as the host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35451
