-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