Hi Carlos and Mark, Your "Relocated compiler should not look in $prefix" patch here:
http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html appears to have caused a regression in my GCC 4.3 testing. In summary, there is a small window *during the GCC build itself* where GCC does not pick up the correct startfiles. For example, when GCC_FOR_TARGET is called to build the target libraries, the startfiles in $prefix/lib are not used. Instead, the startfiles from the host's /usr/lib are used which breaks my build. Note that the problem seems to rectify itself once the just-built GCC is installed into $prefix. Here's the scenario: - Native build - i686-pc-linux-gnu - --prefix=/temptools - Glibc already installed in /temptools/lib Compare the following -v output snippets to demonstrate the problem: GCC 4.2.3 $ /temptools/src/gcc-build/./gcc/xgcc -B/temptools/src/gcc-build/./gcc/ dummy.c -v /mnt/sysroot/temptools/bin/../libexec/gcc/i686-pc-linux-gnu/4.2.3/collect2 --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /temptools/lib/ld-linux.so.2 /mnt/sysroot/temptools/bin/../lib/gcc/i686-pc-linux-gnu/4.2.3/../../../crt1.o GCC 4.3.0-RC1 $ /temptools/src/gcc-build/./gcc/xgcc -B/temptools/src/gcc-build/./gcc/ dummy.c -v /temptools/src/gcc-build/./gcc/collect2 --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker /temptools/lib/ld-linux.so.2 /usr/lib/crt1.o NOTE - I can try to work around the problem by defining STANDARD_STARTFILE_PREFIX_1 and define STANDARD_STARTFILE_PREFIX_2 to "" in the target headers but then the build fails when linking libgcc_s.so.1. /temptools/i686-pc-linux-gnu/bin/ld: crti.o: No such file: No such file or directory I realize my scenario is slightly non-standard, but nevertheless, I'd be grateful if you could pass comment on whether this is a regression or not. I haven't "relocated" anything. All I've done is try to build a native GCC with --prefix=/temptools which used to work fine. Thanks for any help. Thanks Greg
