[Aboriginal] Unable to use gcc inside chroot of latest aboriginal.

[Rob Landley]

Sorry for the delay. Long message to reply to. :)

On 01/17/2016 08:13 PM, James McMechan wrote:
> Hi Rob,
> 
> I decided to follow the example given:
> 
> #more/chroot-splice.sh x86_64 /tmp
> mount: /home/mcmechan/Downloads/aboriginal-1.4.5/build/chroot-x86_64/mnt
> is busy
> Umounting: /home/mcmechan/Downloads/aboriginal-1.4.5/build/chroot-x86_64/mnt
> 
> Ok works on other machines not sure what is happing here.

Neither am I. I should really just modify the script so the /mnt
directory is optional...

Done, you can now call it with one or two arguments.

> #mkdir dummy.dir
> #more/chroot-splice.sh x86_64 dummy.dir
> mount: /home/mcmechan/Downloads/aboriginal-1.4.5/build/chroot-x86_64/mnt
> is busy
> Umounting: /home/mcmechan/Downloads/aboriginal-1.4.5/build/chroot-x86_64/mnt

"is busy"...

You know, that's not a test string toybox mount contains. According to
grep it _is_ a text string ubuntu's mount contains. Is your build/host
directory there on this machine? (If you never ran host-toops.sh it'll
try to use the host's stuff, which varies a bit.)

> I got around that by making a 1M ext2 filesystem just to make the script
> happy and later a patch [1]
> 
> # more/chroot-splice.sh x86_64 dummy.fs
> Aboriginal Linux 1.4.2

Blah, I'm up to 1.4.5 but forgot to update the version number.

I need to make it generate that from the mercurial tags or something.
(It's the etc/os-release file which is what debian switched to when the
declared LSB dead and yanked lsb_release.)

> Type exit when done.
> (x86_64:1) / $ cd aboriginal-1.4.5/
> (x86_64:1) /aboriginal-1.4.5 $ ./build.sh x86_64
> === Download source code.
> <...>
> === Got all source.
> <...>
> === busybox (host host-tools)
> Extracting
> 'busybox'...........................................................................
> Snapshot 'busybox'...
> sh: set: -e: invalid option  
>   HOSTCC  scripts/basic/fixdep
> <..>
> Exiting due to errors (host host-tools busybox)
>
> This seems to be because /usr/bin/sh -> busybox and gives hush?

It's /bin/sh it cares about, but yes. Hush is needed for nommmu support,
but is otherwise a crappy shell. (toysh is on the todo list...)

This is why the root-filesystem image contains bash, and the setup
script for it redirects /bin/sh. Alas, chroot-setup isn't doing the
second cp -la with --remove-desintation. (Fixed.)

> I changed the symlink to bash
> 
> Then toybox/scripts/make.sh tries to use features which are not in /bin/bash
> <...>
> scripts/make.sh: line 7: set: pipefail: invalid option name
> <...>
> Compile toybox.scripts/make.sh: line 1: jobs: command not found
> <...>
> rawcc: generated/obj/xargs.o: No such file or directory
> make: *** [toybox] Error 1
> 
> Exiting due to errors (host host-tools toybox)

Sigh. That's just... Ouch.

(Grrr. Reaaaly tempted to just start next release with toysh
development. Yeah it's a bottomless pit but so's fixing the other shells...)

> Now the only two files overlapping between root-filesystem-x86_64 and
> native-compiler-x86_64 are /bin/sh (busybox/bash) and /usr/bin/strings
> (toybox/binutils)
> 
> Should we manually fix up the problem and if so when? stop building sh
> link in busybox and strings in toybox or just remove them from
> chroot-x86_64 before the second copy in more/choot-splice.sh?

I checked in a fix to chroot-splice.sh. The other problem I have to
think about.

> Noted while mucking about
> 1) escape sequences being stuck in logfiles created with ./build.sh
> $ARCH &>>result.$ARCH
> gets in the way of grep "^===" like in the documentation.

Yup. Part of the problem is that output when it's doing SMP may not put
the === at the start of a line.

> Used echo
> "export NO_TITLE_BAR=1" >> config
> there are quite a few places that have open coded escape sequences that
> end up in the logs

Unfortunately "tty" checks stdin, not stdout...

> the suggestion from the xterm man page is to use printf (POSIX) over
> echo -e (GNU extension) for creating them.

Either way should work, the problem is figuring out _when_ to create them.

> The build system could also detect not going to a terminal with test -t
> 1 either setting NO_TITLE_BAR or having the test before the output, not
> having escape sequences in log files makes searching easier perhaps even
> a NO_ESCAPE_SEQUENCE=1 config symbol?

test -t 1 would work, or I could output a newline before the === (which
would be a blank line in the log but that's fine.)

I note that one use case I have is "cat logfile && tail -f logfile" in
which case the title bar updates to the package it's currently working on...

> 2) toybox has nsenter defaulting to "y" this fails due to not having
> _GNU_SOURCE defined before trying to use setns on debian derived systems

Ah right, I had a todo item for that. (Why debian _won't_ wrap the
syscall is a question for the ages, but I can add a compile-time probe.)

Which debian versions do this? I'd like to set up a test image to
confirm my fix...

> raspberrypi libc6-2.13-38+rpi2+deb7u8 (arm6hf)
> ci20 libc6-2.13-38+deb7u8 (mips32r2)
> both of these are fully up to date as far as I can tell: aptitude
> update, aptitude full-upgrade
> these two boxes are also no longer able to build distcc with
> configure: error: cannot guess build type; you must specify one
> for some reason, I am still looking at this.

I note that my build control images have a trick for that:

http://landley.net/hg/control-images/file/ef471ef37665/common/bootstrap/build-one-package.sh#l31

> 3) dev-environment.sh seems to require that you be in its directory
> before running.
> may I suggest adding the customary
> cd `dirname $0`
> at the start, it might also be helpful for native-build.sh

Good idea.

> all of your other commands seem to need to be run from the aboriginal
> directory. These were different and I had not run them in quite a while.

The more/*.sh commands expect to be run from the aboriginal directory,
yes. (The native-compiler.sh tries to run an ftp server, and no two ftp
servers seem to have the same command line arguments so it assumes
busybox's is in the $PATH...)

> 4) dev-environment.sh prints out about mke2fs being missing before
> updating $PATH
> It is in /sbin which is not in the default path of a ordinary user.  At
> work we have been spending way to much time tightening down our Linux
> boxes, I expect some places ordinary users can't run anything from /sbin
> or /usr/sbin

Hmmm... I have to add mke2fs to toybox. (I wrote half of one a long time
ago but was missing infrastructure. Now I've done that infrastructure
and should get back to it, but I need to do All The Things...)

> which: no mke2fs in
> (/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-
> gnu/gcc-bin/4.9.3:/usr/games/bin)
> 
> It does not seem to be harmful and I am not using the extra virtual hard
> disk but on first glance it looked like it might be a problem...

Well, it is a problem, just not a problem that hits you. There's no
/home mount...

This script knowing /sbin might not be in the path is incestuous
knowledge of specific runtime environments. Exiting the script because
it couldn't find mke2fs isn't the right answer either (

> 5) mips64 still has problems at the moment
> qemu exits on boot with
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a

Yeah, that broke a while back. I was told that the mips64 target qemu
was emulating was a weird one-off board that never went anywhere and
nobody was following up on it. The "nobody following up on it" part
seems to have changed, but the reentry of mips into the 64 bit space is
somewhat incompatible to the previous attempt...

Anyway, the kernel's booting but init is exiting immediately, I need to
track down why. But really, "inability to run hello world when we could
build a kernel" is a uClibc problem, and fixing uClibc isn't interesting
anymore. What I really need to do is interest the musl crowd in adding
mips64 target support, and they're in the middle of a big infrastructure
rewrite to make adding new targets easier.

So that's a todo item, but blocked on pending musl infrastructure updates.

Actually, I should try to get klibc hello world programs running and
then point the musl guys at those for templates...

> Real hardware does not want to run any of the executables past a exec?

Ooh, you have real mips64 hardware!

> # chroot . usr/bin/sh
> # echo *
> bin dev etc home lib mnt proc root sbin sys tmp usr
> # ls
> Segmentation fault
> # chroot . usr/bin/toybox ls
> bin dev etc home lib mnt proc root sbin sys tmp usr

That says the exec syscall is what's screwed up. Which says that the
specific problem is that uClibc and kernel aren't agreeing on syscall
parameters. Hmmm...

That's probably fixable.

> 6) setting the export BUILD=work var in config no longer changes the
> default build destination successfully, I remember using it quite a
> while ago because I disliked the tab-completion of build, also trying to
> figure out why.

I use $BUILD a lot but I admit hardwired "build" has crept in in a few
places. I made something configurable that I never changed, so it never
got tested. These days I tend not to do that, but this project has been
around a while. :)

Grep for "build/" and you'll probably find the culprits.

Rob