[Aboriginal] Interesting case of aboriginal build failure

[Rob Landley]

On 03/18/2012 10:28 PM, Denys Vlasenko wrote:
> On Monday 19 March 2012 01:11, Rob Landley wrote:
>> On 03/17/2012 03:35 PM, Denys Vlasenko wrote:
>>> I've got a native-compiler build failure,
>>> dug a bit deeper, and here what I found:
>>>
>>> The failure happens when we try to run libstdc++-v3 configure.
>>
>> Um, what's the symptom?  (There's an error message?)  Building for which
>> target, from which host, presumably using hg-tip, etc...
> 
> The message is:
> 
> /bin/sh: error while loading shared libraries: libc.so.0: cannot open
> shared object file: No such file or directory
> 
> Basically, it means that attempt to load /bin/sh failed;
> and since we see a library name which is not supposed to be there,
> it strongly suggest that library search path is screwed.
> 
> hg-tip.
> 
> Fedora 16.

Hang on.

libc.so.0 is uClibc.  /bin/sh is the host shell.  And you're running
Fedora 16?

Something doesn't add up here...

>>>        srcdiroption="--srcdir=$${topdir}/libstdc++-v3"; \
>>>        libsrcdir="$$s/libstdc++-v3"; \
>>>        rm -f no-such-file || : ; \
>>> DBG==>  sh </dev/tty >/dev/tty 2>&1; \
>>> FAIL=>  CONFIG_SITE=no-such-file $(SHELL) $${libsrcdir}/configure \
>>>          $(TARGET_CONFIGARGS) $${srcdiroption}  \
>>>          || exit 1
>>> @endif target-libstdc++-v3
>>
>> Huh.  $$ should be current shell PID and then I'd think {srcdiroption}
>> would be passed through verbatim, but that's just a guess.  Weird
>> construction, there...
>>
>> Ah, _make_.  Ok, so $$ becomes literal $ but $(SHELL) and
>> $(TARGET_CONFIGARGS) are both interpreted as make variables.  So from
>> the "FAIL" line's point of view, those are evaluated before the exec()
>> and then the other two are evaluated after by the shell make runs.
>>
>> The above construction is COMPLETELY INSANE because make will _run_ each
>> of its commands through $(SHELL) so if $(SHELL) is /bin/hush and
>> $(TARGET_CONFIGARGS) is "fruit juice" make will do '/bin/hush -c
>> "CONFIG_SITE=no-such-file /bin/hush ${libsrcdir}/configure fruit juice
>> ${srcdiroption} || exit 1"'
>>
>> Which seems kinda roundabout, but *shrug*.
> 
> I think it will run entire multi-line (\-continuated)
> make command via sh -c CMD, not just the part I indicated as "FAIL".

Of course.  But the way sh out of the path works and #!/bin/sh doesn't
is interesting.  Presumably that's busybox ash.

>>> So, I sit in my debug sh session:
>>>
>>> $ ls -l /bin/sh
>>> lrwxrwxrwx    1 root     root             4 Dec  7 15:39 /bin/sh -> bash
>>> ls -l /bin/bash
>>> -rwxr-xr-x    1 root     root        888112 Nov 24 23:00 /bin/bash
>>>
>>> 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.

>>> At this point in build process LD_LIBRARY_PATH is set:
>>>
>>> $ env | grep LIBRARY
>>> LD_LIBRARY_PATH=/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libstdc++-v3/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libmudflap/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libssp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/i686-unknown-linux/libgomp/.libs:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./gcc:/home/srcdevel/aboriginal/aboriginal-1261b8fd1ec9/build/temp-i686/build-gcc/./prev-gcc
>>
>> Huh.  I wonder who set that?
> 
> Presumably, gcc or libstdc++-v3 build machinery.
> 
>>   grep LD_LIBRARY_PATH *.sh sources/*.sh sources/sections/*.sh
>>
>> No hits there.  Hmmm...
>>
>> build/packages/gcc-core/config-ml.in:     ml_config_env="$ml_config_env
>> LD_LIBRARY_PATH=$LD_LIBRARY_PATH_"
>>
>> Ok, I guess that then?
> 
> Probably.
> 
> 
>>> and the following file exists:
>>>
>>> /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).

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.

>> Built by gcc itself, presumably during this very compile run or it
>> wouldn't still be in temp-i686.
> 
> Yes.
> 
> 
>>> Second-to-last LD_LIBRARY_PATH element points to that dir.
>>> Attempt to load /bin/sh -> /bin/bash will load wrong libgcc_s.so.1,
>>> and we end up with:
>>>
>>> /bin/sh: error while loading shared libraries: libc.so.0: cannot open
>>> shared object file: No such file or directory
>>
>> Do you have an /etc/profile that's unsetting LD_LIBRARY_PATH?
> 
> It should not be relevant. Failure happens before /bin/sh
> has a chance to run anything.

I'm going to have to install Fedora Core 16 in a VM and try to reproduce
this breakage...

Rob
-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.

 1332166957.0