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

Alexandre Oliva aoliva@redhat.com
Tue Jan 14 02:06:00 GMT 2003


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-search-no-multilib.patch
Type: text/x-patch
Size: 1448 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20030114/4efda0a7/attachment.bin>
-------------- next part --------------

-- 
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


More information about the Gcc-patches mailing list