[Aboriginal] Interesting case of aboriginal build failure

[Denys Vlasenko]

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.


> In _theory_ the native-compiler stage has been through host-tools.sh and
> the airlock step put only busybox in the $PATH, and you're testing with
> a new busybox version hence the altered behavior?  (I'm guessing here.
> It'll also reach out and take #!/bin/sh and such off the host so distro
> does still matter a bit...)

$PATH is not consulted when kernel processes #!/bin/sh of configure script's
first line; neither it will be considered if $(SHELL) resolves to
absolute name.


> > I added a shell invocation to experiment
> > interactively just before failing command:
> > 
> > build/packages/gcc-core/Makefile.in
> > 
> > configure-target-libstdc++-v3:
> >        ...
> >        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".


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

-- 
vda