-Bdir/ and overriding crt*.o files in multilibbed compilers

[Alexandre Oliva <aoliva at redhat dot com>]

I've learned today that some people expect -Bdir/ to enable a user to
override crt*.o files, and that this is actually true except for
multilibbed settings.  For example, glibc's linuxthreads build system
does that: it creates its own crt[in].o, and it uses -Bdir/ expecting
gcc to find crt[in].o there, instead of in gcc's standard search
paths.

The problem of multilibbed settings is that, when linking for a
non-default multilib, gcc will look for crt*.o files in
-Bdir/-specified directories, but only within multilib directories in
them.  I.e., if you have a system that uses 64/ for a 64-bit multilib,
a 64-bit linuxthreads won't build correctly, since it will be linked
with the pre-installed crt files.

I find it a reasonable expectation for -Bdir/ to search for crt files
in dir/, as long as it can't find them in dir/multilibdir, so I
implemented a patch to that effect.  I can see we might be more
stringent about when to retry without multilibdir, though.  For
example, we might only do that if dir/multilibdir does not exist, or
only for -B-specified directories.  Opinions?

If we're to keep it simple, is this ok to install if it bootstrapped
on a multilibbed system whose multilibs don't interlink (i.e., it
didn't use the wrong crtbegin/crtend during bootstrap in spite of
-B<stage>/ having been specified)?  The only potential
gotcha/functional change that this patch introduces, besides what it's
meant to fix, is that, if you had say:

foo/crti.o
bar/64/crti.o

and you were linking with -Bfoo/ -Bbar/ (in addition to the option
that enables the 64-bit multilib), you'd now get foo/crti.o instead of
bar/64/crti.o, that you got before.  I doubt anyone is actually
relying on this unexpected (to me) behavior.

Index: gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* gcc.c (find_a_file): If searching a non-os_multilib directory,
	if multilib_name fails, try the unadorned name before the next
	directory.

Index: gcc/gcc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/gcc.c,v
retrieving revision 1.357
diff -u -p -r1.357 gcc.c
--- gcc/gcc.c 10 Jan 2003 02:22:02 -0000 1.357
+++ gcc/gcc.c 14 Jan 2003 01:44:02 -0000
@@ -1,6 +1,6 @@
 /* Compiler driver program that can handle many languages.
    Copyright (C) 1987, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-   1999, 2000, 2001, 2002 Free Software Foundation, Inc.
+   1999, 2000, 2001, 2002, 2003  Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -2435,6 +2435,7 @@ find_a_file (pprefix, name, mode, multil
 	const char *this_name
 	  = pl->os_multilib ? multilib_os_name : multilib_name;
 
+      retry:
 	if (machine_suffix)
 	  {
 	    /* Some systems have a suffix for executable files.
@@ -2523,6 +2524,16 @@ find_a_file (pprefix, name, mode, multil
 		  *pl->used_flag_ptr = 1;
 		return temp;
 	      }
+	  }
+
+	/* At least for -Bdirectory/ flags, we should be able to find
+	   object files unadorned by multilib directories, if
+	   searching with the multilib directories couldn't find
+	   them.  */
+	if (! pl->os_multilib && this_name != name)
+	  {
+	    this_name = name;
+	    goto retry;
 	  }
       }
 
-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer