[Aboriginal] Interesting case of aboriginal build failure

[Denys Vlasenko]

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_
requests libc.so.0

>>>> /home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/gcc/libgcc_s.so.1
>
> 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).

Yes.

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

Yes.

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

-- 
vda

 1332167599.0