[Aboriginal] Interesting case of aboriginal build failure
vda.linux at googlemail.com
Mon Mar 19 07:33:19 PDT 2012
On Mon, Mar 19, 2012 at 3:22 PM, Rob Landley <rob at landley.net> wrote:
>>>> Invocation of /bin/sh by configure script's #!/bin/sh
>>>> will try to load my host's /bin/bash. The problem is,
>>>> (running in another, ordinary host shell w/o tweaked environment,
>>>> so that /usr/bin/ldd is accessible and works:)
>>>> $ ldd /bin/bash
>>>> linux-gate.so.1 => (0xb776d000)
>>>> libtinfo.so.5 => /lib/libtinfo.so.5 (0x4bcc8000)
>>>> libdl.so.2 => /lib/libdl.so.2 (0xb7754000)
>>>> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4b017000)
>>>> libc.so.6 => /lib/libc.so.6 (0xb75a6000)
>>>> /lib/ld-linux.so.2 (0xb776e000)
> None of which are libc.so.0.
A wrong libgcc_s.so.1 is picked up from LD_LIBRARY_PATH, and _it_
> Ok, libgcc_s.so.1 is presumably the file that's linked against libc.so.0
> (which is why buildroot happened in the first place).
> And bash is getting confused because the build is including a _target_
> version of libc.so.0 in the _host_ LD_LIBRARY_PATH (which is just as
> wrong when linked against uClibc as it would be if it was an arm binary).
> So how is all this inappropriate crap winding up in LD_LIBRARY_PATH?
> This is why I set CROSS_HOST=`uname -m`-walrus-linux and use
> $ARCH-unknown-linux as the target, so the names will NEVER match and it
> will always be forced down the full cross compiling path instead of
> taking stupid shortcuts.
I know, it's a giant PITA to beat gcc into not doing this :/
More information about the Aboriginal