[Busybox] ppc - compile error
Stewart Brodie
stewart.brodie at pace.co.uk
Mon Aug 19 07:35:03 UTC 2002
In message <3D60EE09.A4A22F35 at opensource.se>
Magnus Damm <damm at opensource.se> wrote:
> >I met an compiling error for ppc.
> >Could you telle me how did you solve this problem?
>
> [snip]
>
> >/lib/libc.so.6: could not read symbols: Invalid operation
> >collect2: ld returned 1 exit status
>
> You are trying to link against /lib/libc.so.6,
> which is the libc for your host system.
>
> In other words:
> The linker "ld" is trying to link together files compiled
> for ppc with the c-library for you host (x86 probably).
>
> This will not work - use the c-library compiled for ppc instead.
I'll report this experience with glibc linking here just in case it's related
to the reported problem. It may be unrelated.
I found that one insidious cause of this error with cross-compiling
toolchains is that the target's libc.so (from glibc) is a linker script which
has a hardwired path which points at /lib/libc.so.6 if you take the one built
for the target (often build with --prefix=/usr when building for Linux)
This can happen if people rebuild glibc and think they can just copy the /lib
and /usr/lib into the toolchain's lib directory. Still, it only took me a
few hours to pick through the files trying to discover why, even with an
explicit link against /usr/tools/mipsel-linux/lib/libc.so, it was still
trying to link /lib/libc.so.6 into my binaries.
So now, I build glibc twice: once for the target, once for the toolchain.
The libc.so linker script is not the only difference, AFAICT. Is there a
documented sane way of doing this properly building it only once?
--
Stewart Brodie, Senior Software Engineer
Pace Micro Technology PLC
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pacemicro.com/
More information about the busybox
mailing list