The cause is this patch which was designed to fix behaviour of relocated compilers:
http://gcc.gnu.org/ml/gcc/2006-10/msg00280.html Unfortunately, it has the side-effect of breaking existing build scripts for *NON* relocated compilers which have relied on this behaviour for years. Contrived procedure to demonstrate the problem (i686-linux): 1. build and install Glibc --prefix=/tmp/foo 2. build and install GCC --prefix=/tmp/foo but prevent startfiles from being found on the host by overriding relevant standard macros eg: echo ' /* Remove /lib and /usr/lib from startfiles search path. */ #define STANDARD_STARTFILE_PREFIX_1 "" #define STANDARD_STARTFILE_PREFIX_2 ""' >> gcc/config/i386/linux.h Above GCC build works fine with GCC-4.2.3 but fails with GCC-4.3.0 when linking libgcc_s.so: /usr/bin/ld: crti.o: No such file: No such file or directory Essentially, the problem is that xgcc thinks it is a relocated compiler when it runs from $objdir eg: when building libgcc* and other target libs, when in actual fact, it is not really a true relocated compiler at all. Attached patch restores the old behaviour, but I'm not proposing it be applied. I suspect that GCC needs a way to distinguish when it is being run from $objdir and when it is truly a relocated compiler. GCC could then behave like it always has and not break the many build procedures that rely on the current behaviour, and truly relocated compilers could also do the right thing. More background in the thread starting here: http://gcc.gnu.org/ml/gcc/2008-03/msg00095.html -- Summary: Native GCC no longer searches $prefix/lib for startfiles when run from $objdir Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gschafer at zip dot com dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532
