[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Slight OT]: Sparc64,32 cross-compiler on x86 - funny problem

Richard Chan <rspchan@starhub.net.sg> writes:

> 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

 You may also want to look at using --use-sysroot

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

 I think you want to add --enable-multilib here.

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

 Have you tried Dan Kegel crossgcc script(s)?

> 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



Reply to: