On Wed, Mar 12, 2008 at 10:44:48PM +1100, Greg Schafer wrote: > Currently, -B doesn't add the multilib search paths when processing > startfile_prefixes. For example, -B $prefix/lib/ doesn't find startfiles in > $prefix/lib/../lib64 > > Most other calls to add_prefix() in gcc.c that refer to startfile_prefixes > do actually process the multilibs. Is there any good reason why -B needs to > be different? Maybe there are assumptions in the GCC build itself that would > break if this were to change.
Ok, finally got around to trying some builds. The change I tested was this: diff -Naur gcc-4.3.0.orig/gcc/gcc.c gcc-4.3.0/gcc/gcc.c --- gcc-4.3.0.orig/gcc/gcc.c 2008-03-02 22:55:19.000000000 +0000 +++ gcc-4.3.0/gcc/gcc.c 2008-03-16 21:39:07.000000000 +0000 @@ -3854,7 +3854,7 @@ add_prefix (&exec_prefixes, value, NULL, PREFIX_PRIORITY_B_OPT, 0, 0); add_prefix (&startfile_prefixes, value, NULL, - PREFIX_PRIORITY_B_OPT, 0, 0); + PREFIX_PRIORITY_B_OPT, 0, 1); add_prefix (&include_prefixes, value, NULL, PREFIX_PRIORITY_B_OPT, 0, 0); n_switches++; Initial signs were encouraging because a standard x86_64 bootstrap with multilib enabled was successful. However, some non-standard build scenarios resulted in build failure when building the 32-bit libgomp (configure test failed to find -lgcc). It seems there are indeed some subtleties introduced by the above as evidenced by this snippet of diffed -print-search-dirs -m32 output: -/temptools/src/gcc-build/./gcc/32/ +/temptools/src/gcc-build/./gcc/../lib/ Therefore, for the time being I withdraw any proposal to modify the -B behaviour. T'is a shame though, because it has the potential to solve the other 4.3 driver problem I reported earlier.. Regards Greg