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
