[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