[Aboriginal] Interesting case of aboriginal build failure

Rob Landley rob at landley.net
Sun Mar 18 17:11:01 PDT 2012

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

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

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

> 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?

  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

Ok, I guess that then?

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

> 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?

I note that when you call bash via the name "sh", the behavior is
different.  From the bash man page:

 --norc Do not read and execute  the  system  wide  initialization  file
        /etc/bash.bashrc  and the personal initialization file ~/.bashrc
        if the shell is interactive.  This option is on  by  default  if
        the shell is invoked as sh.

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


More information about the Aboriginal mailing list