x86->sparc32,64: cross bedevilment

[Richard Chan]

[Also posted to some Sparc/Linux groups in case people have seen this 
before.]

[Executive Summary: The cross build process looks for 32/64-bit target 
binaries
in different places from the runtime cross-compiler - leads to faulty 
cross-compiler
(or build failure) if I forget to rearrange directories before building.

Build process:  64-bit <prefix>/<target>/lib and lib64
                32-bit <prefix>/target>/lib/32

Cross runtime:   64-bit <prefix>/<target>/lib64
                32-bit <prefix>/<target>/lib
]


[Problem]
I am building a Sparc32,64 cross-compiler on x86 for speeding up my 
kernel compiles
on Debian (Gentoo-Sparc & Aurora as well - but that's another story).
Please bear with me as I explain a strange problem that bites me - it 
has to do with
the GCC 3.4.1 build environment not working  with the runtime 
configuration.

During runtime I expect the following behaviour:

prefix = /opt/sparctools
target = sparc64-unknown-linux-gnu

<prefix>/bin/<target>-* are all the cross-tools
<prefix>/<target>/lib has 32-bit libraries copied from a live system
<prefix>/<target>/lib64 has 64-bit libraries copied from a live system
<prefix>/<target>/sys-include has headers copied from a live system

sparc64-unknown-linux-gnu-gcc -m32/-m64 are supposed to pickup the 
correct libraries in
lib/lib64 respectively and can successfully create binaries. By some trial
and error this actually works.
[I want a cross GCC that has the same configure params as the native GCC 
so I have
--enable-shared --enable-threads=posix --enable-languages=c++ 
--enable-__cxa_atexit
--disable-checking --disable-libunwind-exceptions - as a result
target binaries/headers are needed during the build - it looks for 
pthread.h/libc.so etc etc]

The thing that bites is the runtime configuration doesn't work when 
creating the cross-compiler:
the cross-GCC build process is expecting target files as follows:

64-bit: <prefix>/<target>/lib and <prefix>/<target>/lib64
32-bit: <prefix>/<target>lib/32

Merely duplicating 32-bit stuff in lib/32 doesn't work - lib/ must 
contain 64-bit stuff the fallback
to ../lib64 doesn't entirely succeed - although the build proceeds to 
completion the resulting installation
is faulty - some libraries reference a __gmon_start__ symbol as U 
(unknown) leading to link errors
when I try to use the cross-gcc.

Thus there is a mismatch in where the cross-build process is looking for 
target files and where cross-gcc expects
to find them during runtime. So I have a horrible kludge - if I am 
building cross tools I rearrange the library
locations -YUKKKs!!!!

Is there a magic incantation for the cross-build process to tell make 
that 64-bit binaries are in <prefix>/<target>/lib64
and 32-bit binaries are in <prefix>/<target>/lib?

Thanks for reading this long post (and messy problem).

Richard













------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com