[CROSS GCC]: xgcc not using multi-os-directory for ligcc_s.so.1

[Richard Chan <rspchan at starhub dot net dot sg>]

In building a x86->Sparc32,64 cross I encountered the situation where 
xgcc is not using
the multi-os-directory when building libgcc_s.so.1. This results in 
finding the wrong target
crt*.o files (32-bit) when trying to build 64-bit libgcc_s.so.1.

Problem description

Building an x86->Sparc32,64 cross using
configure
--prefix=/opt/sparctools --target=sparc64-unknown-linux-gnu
--enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions
--disable-optimization --with-system-zlib

The target files (necessary for pthread.h, libc.so etc) have been copied 
over
from a live system:

32-bit files in <prefix>/<target>/lib
64-bit files in<prefix>/<target>lib64
System headers in <prefix>/<target>/sys-include


The building of 32/64-bits gcc has two quirks:

the 32-bit build looks in lib/32 for target files - if I duplicate 
32-bit target files
- there is no problem; build succeeds and resulting cross-compiler can 
build
32-bit binaries (however at runtime it no longer uses lib/32 directory 
--- it is
satisfied with looking of 32-bit libraries in lib/).

the 64-bit build of libgcc_s.so.1 is definitely b0rked: xgcc will build 
it with
-B<prefix>/<target>/lib and -B<prefix>/<target>/lib64 - this looks ok, but
it will get the 32-bit crt*.o files instead of falling back to the 
64-bit crt*.o files
---the resulting libgcc_s.so.1 is faulty (__gmon_start__ symbol is a U 
instead of
being changed to a call_gmon_start etc) ---study of the error messages 
show that
it is definitely picking up the 32-bit crtX.o files.

I would expect xgcc to use the --multi-os-directory ../lib64 at this 
stage. If I manually
interfere with the build when libgcc_s.so.1(64-bit) is being built by 
adding
-B<prefix>/<target>/lib/../lib64 (#simulate adding on the 
multi-os-directory)
everything builds correctly.

Is this is a bug? Actually I want the cross build process to understand 
that
lib/ (resp. lib64/) has all the target files needed for the -m32 (resp. 
-m64) compiler
and weird hoop-jumping like using lib/32 (for 32-bits) and lib/ before 
lib64/ (for 64-bits)
is not necessary.

(BTW at runtime the cross-compiler is fine and building 32-bit and 
64-bit binaries is working
correctly;  -m64 always looks in lib64/ first due to multi-os-directory 
= ../lib64.
there just seems to be a mismatch of expectations between the runtime and
build time systems.)

Thanks
richard