From rob at landley.net Sun Jan 3 22:00:00 2016 From: rob at landley.net (Rob Landley) Date: Sun, 3 Jan 2016 16:00:00 -0600 Subject: [Aboriginal] Can Aboriginal Linux be used to create a Debian rootfs In-Reply-To: <563DD9F4.4070103@etrix.com.au> References: <5632C2D5.7090109@etrix.com.au> <5632FB37.4070907@landley.net> <563DD9F4.4070103@etrix.com.au> Message-ID: <568999E0.8030809@landley.net> Sorry this fell through the cracks, busy few months. (And Dreamhost decided to eat the mailing list web archive _again_. Kinda annoyed at them. There's still _11 months_ missing. We may be light traffic here with most of the action in toybox at the moment, but not _that_ light.) On 11/07/2015 05:01 AM, Brendan Simon (eTRIX) wrote: > On 30/10/2015 4:08 PM, Rob Landley wrote: >> On 10/29/2015 08:07 PM, Brendan Simon (eTRIX) wrote: >>> Hi. Just stumbled across Aboriginal Linux and it looks like an great >>> project :) >>> >>> I am trying to create a Debian rootfs for an embedded system that uses >>> Dual ARM A9 cores (Xilinx Zynq SoC). >>> >>> I'm currently trying to use multistrap (from the Emdebian project) and >>> am now trying moved to brickstrap (a fork of polystrap which is a fork >>> of multistrap). Brickstrap does everything in userspace via proot and >>> uses QEMU for the final configuration phase. >>> >>> I was wondering if it is possible to use Aboriginal Linux to do some or >>> all of this? i.e. create a Debian rootfs from debian binary packages. >>> Would it be simpler? >> In theory, yes. In practice, it's a big todo item as explained here: >> >> http://landley.net/aboriginal/about.html#hairball >> >> For Debian I've been vaguely looking at: >> >> https://wiki.debian.org/HelmutGrohne/rebootstrap > > I've had success with Brickstrap (well in creating a rootfs, but not > tested yet). Brickstrap now uses Linux user namespaces instead of proot. > > https://blog.mister-muffin.de/category/linux/ Blog categories isn't quite a proper replacement for a project page. (I have this problem with ellcc.org as well...) > The project/tool is called 'user-unshare', but it looks like it is going > to be call uroot (as it is intended as a replacement for proot). > > https://gitlab.mister-muffin.de/josch/user-unshare Which sounds like a replacement for fakeroot? I boot virtual systems under qemu so I don't need to do that, I can give the build environment root in its own restricted space. (Although "container" vs "vm" is a thing that I never did write up my SCALE talk on. I see the appeal of doing it in containers, I just can't do an arm container on an x86 system without the qemu application emulation can of worms...) > Brickstrap uses user-unshare, multistrap and libguestfs to create my > rootfs from .deb packages via apt, and configure them, creates a disk > image, all without requiring superuser rights :) It sounds very interesting. However, I'd rather have something with fewer dependencies operating in a container or vm where it thinks it has superuser rights. Aboriginal creates a system image without superuser rights, and then uses qemu to boot that system image in a VM where it has full (emulated) hardware access. That's the replacing cross compiling with native compiling stuff from the 2008 presentation. Anyway, I am interested in following up on this, just... a bit overstretched the past few years. :) > Cheers, Brendan. Rob 1451858400.0 From rob at landley.net Fri Jan 8 06:36:16 2016 From: rob at landley.net (Rob Landley) Date: Fri, 8 Jan 2016 00:36:16 -0600 Subject: [Aboriginal] 1.4.4 is out. Message-ID: <568F58E0.3080407@landley.net> Notice on the mailing list. No, I don't know when dreamhost might fix the web archive. Feel free to ask them? Rob 1452234976.0 From dahalls at gmail.com Fri Jan 8 07:38:13 2016 From: dahalls at gmail.com (David Halls) Date: Fri, 8 Jan 2016 07:38:13 +0000 Subject: [Aboriginal] 1.4.4 is out. In-Reply-To: <568F58E0.3080407@landley.net> References: <568F58E0.3080407@landley.net> Message-ID: Thanks Rob- been looking forward to moving to musl. On 8 January 2016 at 06:36, Rob Landley wrote: > Notice on the mailing list. > > No, I don't know when dreamhost might fix the web archive. Feel free to > ask them? > > Rob > _______________________________________________ > Aboriginal mailing list > Aboriginal at lists.landley.net > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Fri Jan 8 16:39:09 2016 From: rob at landley.net (Rob Landley) Date: Fri, 8 Jan 2016 10:39:09 -0600 Subject: [Aboriginal] 1.4.4 is out. In-Reply-To: References: <568F58E0.3080407@landley.net> Message-ID: <568FE62D.5000402@landley.net> On 01/08/2016 01:38 AM, David Halls wrote: > Thanks Rob- been looking forward to moving to musl. So have I, but the native builds of strace and linux from scratch are still broken. Musl was never interested in being a drop-in replacement for existing libraries, so we have to adapt to it. (Primarily its refusal to identify itself with an #ifdef MUSL. I can patch that in locally, and I think I actually have, but that doesn't mean packages will use it unless I can get that standardized.) Rob 1452271149.0 From ska-devel at skarnet.org Fri Jan 8 16:50:53 2016 From: ska-devel at skarnet.org (Laurent Bercot) Date: Fri, 8 Jan 2016 17:50:53 +0100 Subject: [Aboriginal] 1.4.4 is out. In-Reply-To: <568FE62D.5000402@landley.net> References: <568F58E0.3080407@landley.net> <568FE62D.5000402@landley.net> Message-ID: <568FE8ED.2030802@skarnet.org> On 08/01/2016 17:39, Rob Landley wrote: > So have I, but the native builds of strace and linux from scratch are > still broken. Just in case you still don't have the patch for strace-4.10 and didn't rewrite it yourself: here it is. -- Laurent From: Felix Janda Date: Sat, 28 Mar 2015 18:40:13 +0100 Subject: [PATCH] Include for _IOC_* macros Fix a compilation failure with musl libc. * evdev.c: Include . * ioctl.c: Include instead of . * ioctlsort.c: Likewise. Reported-by: Dima Krasner Acked-by: Mike Frysinger --- evdev.c | 2 ++ ioctl.c | 2 +- ioctlsort.c | 2 +- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/evdev.c b/evdev.c index 9a7430d..e06f9c1 100644 --- a/evdev.c +++ b/evdev.c @@ -28,6 +28,8 @@ #include "defs.h" +#include + #ifdef HAVE_LINUX_INPUT_H #include #include "xlat/evdev_abs.h" diff --git a/ioctl.c b/ioctl.c index 46f8334..c67d048 100644 --- a/ioctl.c +++ b/ioctl.c @@ -29,7 +29,7 @@ */ #include "defs.h" -#include +#include #include "xlat/ioctl_dirs.h" #ifdef HAVE_LINUX_INPUT_H diff --git a/ioctlsort.c b/ioctlsort.c index 333556c..9c31691 100644 --- a/ioctlsort.c +++ b/ioctlsort.c @@ -33,7 +33,7 @@ #include #include #include -#include +#include struct ioctlent { const char *info; -- 1.9.1 1452271853.0 From piotr.karbowski at gmail.com Sat Jan 9 20:54:23 2016 From: piotr.karbowski at gmail.com (KARBOWSKI Piotr) Date: Sat, 9 Jan 2016 21:54:23 +0100 Subject: [Aboriginal] Unable to use gcc inside chroot of latest aboriginal. Message-ID: <5691737F.8070805@gmail.com> Hi, It seems that something is kind of broken with the GCC when used in chroot. When I combine the root-filesystem with native-compiller and chroot there, the gcc runs cc, which then fails to run 'rawcc'. Appending the /usr/*-unknown-linux/bin/ to $PATH does make gcc no longer crash like that, but I think it was not intendent to require altering $PATH. -- Piotr. 1452372863.0 From rob at landley.net Mon Jan 11 01:00:26 2016 From: rob at landley.net (Rob Landley) Date: Sun, 10 Jan 2016 19:00:26 -0600 Subject: [Aboriginal] Unable to use gcc inside chroot of latest aboriginal. In-Reply-To: <5691737F.8070805@gmail.com> References: <5691737F.8070805@gmail.com> Message-ID: <5692FEAA.10104@landley.net> On 01/09/2016 02:54 PM, KARBOWSKI Piotr wrote: > Hi, > > It seems that something is kind of broken with the GCC when used in > chroot. There's a more/chroot-splice.sh script that sets up a chroot, which works fine for me here? (It requires a control image to mount on /mnt, but you can feed it an empty directory.) > When I combine the root-filesystem with native-compiller and > chroot there, the gcc runs cc, which then fails to run 'rawcc'. How are you combining the two? > Appending the /usr/*-unknown-linux/bin/ to $PATH does make gcc no longer > crash like that, but I think it was not intendent to require altering > $PATH. It wasn't. You should be able to basically: mkdir out cp -a dir1/. out cp -a dir2/. out chroot out (Without the /. cp has an annoying habit of creating out/dir1 or out/dir2 but that's a cp issue inherent to posix...) What chroot-splice.sh does is actually: # Copy root filesystem and native compiler cp -lan "build/root-filesystem-$1/." "$CHROOT" || exit 1 cp -lan "build/native-compiler-$1/." "$CHROOT" || exit 1 The -l hardlinks the original files rather than creating a new copy. The sbin/init.sh script under qemu (from sources/root-filesystem/sbin/init.sh) does: [ -b /dev/[hsv]da ] && mkdir -p /usr/overlay && mount /dev/[hsv]da /usr/overlay and then: # Call overlay/init if available [ -e /usr/overlay/init ] && . /usr/overlay/init Which comes from sources/toys/hdainit.sh and starts with: # splice hda into / cp -rFs /usr/overlay/. / So chroot_splice.sh is doing cp -ln (hardlink, no overwrite) and that's doing cp -Fs (delete destination file first (if any), symlink). The only conflicting file between the two should be /bin/sh by the way. (Switching from hush to bash 2.05b.) Rob 1452474026.0 From rob at landley.net Tue Jan 12 03:29:15 2016 From: rob at landley.net (Rob Landley) Date: Mon, 11 Jan 2016 21:29:15 -0600 Subject: [Aboriginal] 1.4.5 release. Message-ID: <5694730B.50903@landley.net> Just cut another dot release, but all I updated was the kernel version. 4.4 came out so I cut a release with 4.3 just to get caught up. I should have one more release in the next month or so, with 4.4 and a new toybox and build control images that work with musl, plus converting at least sh2eb over to musl. For the record, the remaining tarrgts that use uClibc are: armv4l - because EABI requires thumb m68k - no musl port mips64 - no musl port sparc - no musl port I can probably fiddle with --fix-v4bx and get armv4l switched over to musl too. The other three require adding new target support to musl. I also have (locally) the start of alpha and s390x support, neither of which is in musl (but both are in klibc). I started poking at both because qemu-system-alpha and qemu-system-s390x both exist and can boot debian images, although in s390x's case uClibc never had support (the image was glibc). Rob 1452569355.0 From rob at landley.net Tue Jan 12 04:52:23 2016 From: rob at landley.net (Rob Landley) Date: Mon, 11 Jan 2016 22:52:23 -0600 Subject: [Aboriginal] what fork should I use to get q800-capable qemu-m68k? In-Reply-To: References: Message-ID: <56948687.2000803@landley.net> On 12/20/2015 07:53 AM, Warren Postma wrote: > Because my tastes run towards antiquity, when I found out about > aboriginal linux, I of course wanted to try the oldest and weirdest > port you had. Nobody has gotten Linux running on an emulated PDP-11 > yet, have they? According to Rich Felker there is a pdp 11 gcc out there, but alas twitter won't let me look far enough back in his timeline to find the link. > The m68k q800 emulator appears from the mailing list archive to be a > simulation of the last of the 68030 macintosh systems, so that's the > first one I downloaded, natch. Back in the day, my sympathies were > with the 680x0 Amigas, but that's close enough. Aranym is an atari m68k emulator, which people got our m68k root filesystem working with before Laruent's qemu fork worked. Alas, it required kernel patches and was non-obvious to build and run. > Google, salva nos inscius, lead me to > https://github.com/vivier/qemu-m68k/wiki which hath branch 680x0-v2.3.0 You need the q800 branch. Then ./configure --target-list=m68k-softmmu and build it, just confirmed the result works with the q800-2.4.0 branch. > I have never built qemu from sources, so I found this ask > ubuntu-question to get me past the DTC lib issue, I manually grabbed the > tarball and unzipped into the /dtc/ folder... > > http://askubuntu.com/questions/424329/error-trying-to-compile-qemu-from-source It's kinda horrible, you can do the git subrepo init thing it suggests for dtc and another package (pixman?), have to install two more packages to your host, and then the build breaks because it wants autoconf installed... > After that ./configure complains about broken libtool, but completes. Nobody ever needs libtool for anything, it makes non-elf systems behave like elf. Linux has been ELF since 1996. The fact libtool is a NOP yet fails to do nothing successfully is the FSF in a nutshell. > make got in a fair way, and the compile breaks while building > aarch64-linux-user. I am too much of a noob to figure out what to > configure out to make this go away or if aarch64-linux-user is some > basic part of this qemu build: Never use snapshot du jour your first time building a project, pick a release version. If the project doesn't have release versions, pick a different project. > Has anyone built an m68k q800 capable qemu on Ubuntu? Yes, me, just now. The --target-list=m68k-softmmu thing tells it to build JUST the target you want. ("softmmu" means system emulation, m68k-user builds user emulation. The first boots a kernel and translates hardware access attempts, the second runs an elf binary and translates system calls. Turns out system calls are way more work to translate than hardware access, so system emulation is noticeably more reliable. It never has to worry about data passing through some random /proc file needing to be parsed and rewritten.) > Are there any > more tricks? Could I just turn off some element of the qemu build and > get the qemu cpu-emulator up without any userland emulation? I'm > guessing this syscall mechanism is actually central to qemu + > aboriginal-linux functionality as it's probably how I/O occurs inside > the emulator. I should poke Laurent about getting his work merged upstream. (Again.) http://lists.landley.net/pipermail/aboriginal-landley.net/2013-October/001306.html (Dreamhost didn't delete the ENTIRE archive. Just the last year of it...) > Cheers. > > Warren Rob 1452574343.0 From piotr.karbowski at gmail.com Sat Jan 16 14:57:04 2016 From: piotr.karbowski at gmail.com (KARBOWSKI Piotr) Date: Sat, 16 Jan 2016 15:57:04 +0100 Subject: [Aboriginal] Unable to use gcc inside chroot of latest aboriginal. In-Reply-To: <5692FEAA.10104@landley.net> References: <5691737F.8070805@gmail.com> <5692FEAA.10104@landley.net> Message-ID: <569A5A40.9020308@gmail.com> Hi, On 01/11/2016 02:00 AM, Rob Landley wrote: > How are you combining the two? I tried cp -a, cp -al, rsync -a and every time I am getting the same issue. To reproduce the issue one can just: 1. fetch aboriginal hg. 2. run ./build.sh x86_64 3. jump to root 4. mkdir foo && cd foo 5. cp -al ../build/root-filesystem-x86.64/. . 6. cp -al ../build/native-compiler-x86_64/. . 7. chroot . /bin/sh 8. run gcc I tried also env -i chroot . /bin/bash --login, and then export PATH (because PATH was set, but not exported) but still the same issue. rawcc: No such file or directory. -- Piotr. 1452956224.0 From rob at landley.net Sun Jan 17 06:53:34 2016 From: rob at landley.net (Rob Landley) Date: Sun, 17 Jan 2016 00:53:34 -0600 Subject: [Aboriginal] Unable to use gcc inside chroot of latest aboriginal. In-Reply-To: <569A5A40.9020308@gmail.com> References: <5691737F.8070805@gmail.com> <5692FEAA.10104@landley.net> <569A5A40.9020308@gmail.com> Message-ID: <569B3A6E.7090200@landley.net> On 01/16/2016 08:57 AM, KARBOWSKI Piotr wrote: > Hi, On 01/11/2016 02:00 AM, Rob Landley wrote: >> How are you combining the two? > > I tried cp -a, cp -al, rsync -a and every time I am getting the same issue. > > To reproduce the issue one can just: > > 1. fetch aboriginal hg. > 2. run ./build.sh x86_64 > 3. jump to root > 4. mkdir foo && cd foo > 5. cp -al ../build/root-filesystem-x86.64/. . > 6. cp -al ../build/native-compiler-x86_64/. . > 7. chroot . /bin/sh > 8. run gcc You didn't run sbin/init.sh so your path didn't get set. > I tried also env -i chroot . /bin/bash --login, and then export PATH > (because PATH was set, but not exported) but still the same issue. > rawcc: No such file or directory. Yeah, poking at it earlier today I stopped at the "path not exported" part, but looking at it again with the default PATH=/bin:/sbin it's working, but with /usr/bin/gcc being found first, the relative paths aren't set up right. Hmmm... strace is finding: execve("(null)/bin/rawcc", ["rawcc"], [/* 16 vars */]) = -1 ENOENT (No such file or directory) Which clearly isn't right; something's gone pear shaped and topdir isn't set. (There's an explicit test for that, so it got unset _after_ that test... Hmmm...) So yes, by intentionally ignoring the working examples provided (more/setup-chroot.sh and such), you did indeed find a bug. Thanks for the heads up. Rob 1453013614.0 From piotr.karbowski at gmail.com Sun Jan 17 09:29:02 2016 From: piotr.karbowski at gmail.com (KARBOWSKI Piotr) Date: Sun, 17 Jan 2016 10:29:02 +0100 Subject: [Aboriginal] Unable to use gcc inside chroot of latest aboriginal. In-Reply-To: <569B3A6E.7090200@landley.net> References: <5691737F.8070805@gmail.com> <5692FEAA.10104@landley.net> <569A5A40.9020308@gmail.com> <569B3A6E.7090200@landley.net> Message-ID: <569B5EDE.5010609@gmail.com> Hi, On 01/17/2016 07:53 AM, Rob Landley wrote: > So yes, by intentionally ignoring the working examples provided > (more/setup-chroot.sh and such), you did indeed find a bug. Thanks for > the heads up. Actually, I've tried to use it the same way I always used aboriginal 1.2.0 and older. Just chroot and used to work. And it seems the init.sh does not really work, toybox bug? The chroot-splice.sh runs CPUS=1 HOST="$1" chroot "$CHROOT" /sbin/init.sh where the $1 is arch, so x86_64 for me. If I run it manually, then I am getting a load of syntax errors. kurogane aboriginal # CPUS='1' HOST='x86_64' chroot ./foo /sbin/init.sh sed: invalid integer argument s/PRETTY_NAME="\([^"]*\)"/\1/p mountpoint: invalid option -- q Usage: mountpoint [option(s)] [file(s)] Display printable strings in [file(s)] (stdin by default) The options are: -a - --all Scan the entire file, not just the data section -f --print-file-name Print the name of the file before each string -n --bytes=[number] Locate & print any NUL-terminated sequence of at - least [number] characters (default 4). -t --radix={o,d,x} Print the location of the string in base 8, 10 or 16 -o An alias for --radix=o -T --target= Specify the binary file format -e --encoding={s,S,b,l,B,L} Select character size and endianness: s = 7-bit, S = 8-bit, {b,l} = 16-bit, {B,L} = 32-bit @ Read options from -h --help Display this information -v --version Print the program's version number mountpoint: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex Usage: mount [option(s)] [file(s)] Display printable strings in [file(s)] (stdin by default) The options are: -a - --all Scan the entire file, not just the data section -f --print-file-name Print the name of the file before each string -n --bytes=[number] Locate & print any NUL-terminated sequence of at - least [number] characters (default 4). -t --radix={o,d,x} Print the location of the string in base 8, 10 or 16 -o An alias for --radix=o -T --target= Specify the binary file format -e --encoding={s,S,b,l,B,L} Select character size and endianness: s = 7-bit, S = 8-bit, {b,l} = 16-bit, {B,L} = 32-bit @ Read options from -h --help Display this information -v --version Print the program's version number mount: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex mountpoint: invalid option -- q Usage: mountpoint [option(s)] [file(s)] Display printable strings in [file(s)] (stdin by default) The options are: -a - --all Scan the entire file, not just the data section -f --print-file-name Print the name of the file before each string -n --bytes=[number] Locate & print any NUL-terminated sequence of at - least [number] characters (default 4). -t --radix={o,d,x} Print the location of the string in base 8, 10 or 16 -o An alias for --radix=o -T --target= Specify the binary file format -e --encoding={s,S,b,l,B,L} Select character size and endianness: s = 7-bit, S = 8-bit, {b,l} = 16-bit, {B,L} = 32-bit @ Read options from -h --help Display this information -v --version Print the program's version number mountpoint: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex Usage: mount [option(s)] [file(s)] Display printable strings in [file(s)] (stdin by default) The options are: -a - --all Scan the entire file, not just the data section -f --print-file-name Print the name of the file before each string -n --bytes=[number] Locate & print any NUL-terminated sequence of at - least [number] characters (default 4). -t --radix={o,d,x} Print the location of the string in base 8, 10 or 16 -o An alias for --radix=o -T --target= Specify the binary file format -e --encoding={s,S,b,l,B,L} Select character size and endianness: s = 7-bit, S = 8-bit, {b,l} = 16-bit, {B,L} = 32-bit @ Read options from -h --help Display this information -v --version Print the program's version number mount: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex mountpoint: invalid option -- q Usage: mountpoint [option(s)] [file(s)] Display printable strings in [file(s)] (stdin by default) The options are: -a - --all Scan the entire file, not just the data section -f --print-file-name Print the name of the file before each string -n --bytes=[number] Locate & print any NUL-terminated sequence of at - least [number] characters (default 4). -t --radix={o,d,x} Print the location of the string in base 8, 10 or 16 -o An alias for --radix=o -T --target= Specify the binary file format -e --encoding={s,S,b,l,B,L} Select character size and endianness: s = 7-bit, S = 8-bit, {b,l} = 16-bit, {B,L} = 32-bit @ Read options from -h --help Display this information -v --version Print the program's version number mountpoint: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex Usage: mount [option(s)] [file(s)] Display printable strings in [file(s)] (stdin by default) The options are: -a - --all Scan the entire file, not just the data section -f --print-file-name Print the name of the file before each string -n --bytes=[number] Locate & print any NUL-terminated sequence of at - least [number] characters (default 4). -t --radix={o,d,x} Print the location of the string in base 8, 10 or 16 -o An alias for --radix=o -T --target= Specify the binary file format -e --encoding={s,S,b,l,B,L} Select character size and endianness: s = 7-bit, S = 8-bit, {b,l} = 16-bit, {B,L} = 32-bit @ Read options from -h --help Display this information -v --version Print the program's version number mount: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex hush: can't execute 'mdev': No such file or directory mkdir: invalid option -- p Usage: mkdir [option(s)] [file(s)] Display printable strings in [file(s)] (stdin by default) The options are: -a - --all Scan the entire file, not just the data section -f --print-file-name Print the name of the file before each string -n --bytes=[number] Locate & print any NUL-terminated sequence of at - least [number] characters (default 4). -t --radix={o,d,x} Print the location of the string in base 8, 10 or 16 -o An alias for --radix=o -T --target= Specify the binary file format -e --encoding={s,S,b,l,B,L} Select character size and endianness: s = 7-bit, S = 8-bit, {b,l} = 16-bit, {B,L} = 32-bit @ Read options from -h --help Display this information -v --version Print the program's version number mkdir: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex mountpoint: invalid option -- q Usage: mountpoint [option(s)] [file(s)] Display printable strings in [file(s)] (stdin by default) The options are: -a - --all Scan the entire file, not just the data section -f --print-file-name Print the name of the file before each string -n --bytes=[number] Locate & print any NUL-terminated sequence of at - least [number] characters (default 4). -t --radix={o,d,x} Print the location of the string in base 8, 10 or 16 -o An alias for --radix=o -T --target= Specify the binary file format -e --encoding={s,S,b,l,B,L} Select character size and endianness: s = 7-bit, S = 8-bit, {b,l} = 16-bit, {B,L} = 32-bit @ Read options from -h --help Display this information -v --version Print the program's version number mountpoint: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex Usage: mount [option(s)] [file(s)] Display printable strings in [file(s)] (stdin by default) The options are: -a - --all Scan the entire file, not just the data section -f --print-file-name Print the name of the file before each string -n --bytes=[number] Locate & print any NUL-terminated sequence of at - least [number] characters (default 4). -t --radix={o,d,x} Print the location of the string in base 8, 10 or 16 -o An alias for --radix=o -T --target= Specify the binary file format -e --encoding={s,S,b,l,B,L} Select character size and endianness: s = 7-bit, S = 8-bit, {b,l} = 16-bit, {B,L} = 32-bit @ Read options from -h --help Display this information -v --version Print the program's version number mount: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 efi-app-x86_64 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex grep: 'default for QEMU': No such file date: '+%s': No such file hush: out of range Type exit when done. (x86_64:1) / $ I think something went wrong and I am pretty sure I am doing it exactly as the working example shows. Combine two dirs, then chroot with running init.sh. Seems kind of like broken toybox to me. Anything that is symlinked to toybox does not work here, I mean, it prints the very same help/error output, looks like its `strings`. My host is pretty normal. The only thing you may found uncommon is that I am running NILFS2 on the very partition I build and run aboriginal from. (Actually I've run into issues where bind-mounting NILFS2 partition spawn another garbage collector for nilfs, shoudn't imo). -- Piotr. 1453022942.0 From piotr.karbowski at gmail.com Sun Jan 17 09:55:32 2016 From: piotr.karbowski at gmail.com (KARBOWSKI Piotr) Date: Sun, 17 Jan 2016 10:55:32 +0100 Subject: [Aboriginal] Unable to use gcc inside chroot of latest aboriginal. In-Reply-To: <569B5EDE.5010609@gmail.com> References: <5691737F.8070805@gmail.com> <5692FEAA.10104@landley.net> <569A5A40.9020308@gmail.com> <569B3A6E.7090200@landley.net> <569B5EDE.5010609@gmail.com> Message-ID: <569B6514.3060305@gmail.com> On 01/17/2016 10:29 AM, KARBOWSKI Piotr wrote: > Seems kind of like broken toybox to me. Anything that is symlinked to > toybox does not work here, I mean, it prints the very same help/error > output, looks like its `strings`. Okey, I wasn't running cp with -n, which was resulting in overwritting the strings symlink with strings binary, which was actually overwritting the toybox binary with strings... So yeah, running chroot ./foo /sbin/init.sh gives me working gcc. Btw, exiting from the 'chroot ./foo /sbin/init.sh' somehow breaks my host's /dev/pts and I am no longer able to spawn any terminal... -- Piotr. 1453024532.0 From rob at landley.net Sun Jan 17 16:40:28 2016 From: rob at landley.net (Rob Landley) Date: Sun, 17 Jan 2016 10:40:28 -0600 Subject: [Aboriginal] Unable to use gcc inside chroot of latest aboriginal. In-Reply-To: <569B6514.3060305@gmail.com> References: <5691737F.8070805@gmail.com> <5692FEAA.10104@landley.net> <569A5A40.9020308@gmail.com> <569B3A6E.7090200@landley.net> <569B5EDE.5010609@gmail.com> <569B6514.3060305@gmail.com> Message-ID: <569BC3FC.8060607@landley.net> On 01/17/2016 03:55 AM, KARBOWSKI Piotr wrote: > On 01/17/2016 10:29 AM, KARBOWSKI Piotr wrote: >> Seems kind of like broken toybox to me. Anything that is symlinked to >> toybox does not work here, I mean, it prints the very same help/error >> output, looks like its `strings`. > > Okey, I wasn't running cp with -n, which was resulting in overwritting > the strings symlink with strings binary, which was actually overwritting > the toybox binary with strings... I was replying to your first message and went "lemme read the second..." :) > So yeah, running chroot ./foo /sbin/init.sh gives me working gcc. > > Btw, exiting from the 'chroot ./foo /sbin/init.sh' somehow breaks my > host's /dev/pts and I am no longer able to spawn any terminal... That's really weird. The cleanup from the chroot is done _within_ the chroot, and shouldn't have access to your host mount points. The mountpoint is created via: mountpoint -q dev/pts || mount -t devpts dev/pts dev/pts And the end of the init script is just: echo Type exit when done. /bin/hush cd / umount ./dev/pts umount ./dev umount ./sys umount ./proc sync So we mount -t devpts and then umount it again. It sounds like your kernel is unmounting every instance of -t devpts when any instance is unmounted? Hmmm... https://www.kernel.org/doc/Documentation/filesystems/devpts.txt To support containers, we now allow multiple instances of devpts filesystem, such that indices of ptys allocated in one instance are independent of indices allocated in other instances of devpts. To preserve backward compatibility, this support for multiple instances is enabled only if: - CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, and - '-o newinstance' mount option specified while mounting devpts So the behavior changed there, but git annotate says the documentation change was in 2009... Either way, that's a kernel issue in your host system. > -- Piotr. Rob 1453048828.0 From james.w.mcmechan at gmail.com Mon Jan 18 02:13:21 2016 From: james.w.mcmechan at gmail.com (James McMechan) Date: Sun, 17 Jan 2016 18:13:21 -0800 Subject: [Aboriginal] Unable to use gcc inside chroot of latest aboriginal. In-Reply-To: <569B3A6E.7090200@landley.net> References: <5691737F.8070805@gmail.com> <5692FEAA.10104@landley.net> <569A5A40.9020308@gmail.com> <569B3A6E.7090200@landley.net> Message-ID: 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. #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 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 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? 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) 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? 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. 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 the suggestion from the xterm man page is to use printf (POSIX) over echo -e (GNU extension) for creating 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? 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 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. 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 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. 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 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... 5) mips64 still has problems at the moment qemu exits on boot with Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a Real hardware does not want to run any of the executables past a exec? # 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 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: chroot-splice.patch Type: text/x-patch Size: 1353 bytes Desc: not available URL: From tristan.vanberkom at codethink.co.uk Wed Jan 20 15:00:28 2016 From: tristan.vanberkom at codethink.co.uk (Tristan Van Berkom) Date: Thu, 21 Jan 2016 00:00:28 +0900 Subject: [Aboriginal] Proposed patches to support modern toolchain Message-ID: <1453302028.25793.51.camel@codethink.co.uk> [Sorry for double post, first one got stuck in moderation queue as it was too large, this time used xz compression for patches and it should hopefully fit] Hello Aboriginal Mailing List ! ????As some who have been present on irc are aware, I have been working on a patch set to allow aboriginal linux to build with the a more recent (GPLv3 infected) toolchain. The initial patch set is working now, I have built and tested the compiler and distcc on the resulting images for invocations with CROSS_COMPILER_HOST=i686 for the armv5l and mips images. This passes nicely and the resulting image works with your regular dev-environment.sh invocation, the compiler builds hello world in C and C++ and also successfully distributes compilation over distcc to the cross compiler. In this mail I will outline the proposed changes implemented by this patch set, along with any caveats and/or observations I can think of at the time of writing it. The patch set however documents itself also. To try the patchset, I have created a temporary github to hold the patch set, which is based on the 1.4.5 tarball recently released: ????https://github.com/gtristan/aboriginal-gcc-5.3-support.git I will also attach the patches to this email in a tarball as that may be more practical to apply locally. Enjoy ! Best Regards, ????-Tristan Overview ~~~~~~~~ This patchset does not replace the existing GPLv2 toolchain but instead adds the newer toolchain in such a way that you may choose which toolchain to build. Currently, only musl flavored builds are available with the modern toolchain, it is possible to try and fix that so as to build uClibc with GCC 5.3, if that is desirable to some, but is just currently not supported. By default, the build will continue to build the GPLv2 toolchain, in order to build the new toolchain you need only specify ENABLE_GPLV3=1 In order to allow multiple builds of the same package (i.e. for gcc and binutils) I have made some changes to functions.sh and download_function.sh. These changes are implemented in their own isolated patch to ease the review process. Changes to the payload ~~~~~~~~~~~~~~~~~~~~~~ This patch set introduces the following packages and patches to the build. ? Binutils 2.25.1 ? ~~~~~~~~~~~~~~~ ? Latest release tarball of binutils. ? I have also included the musl related patches, imported from the ? musl-cross-make project[0]. ? GCC 5.3.0 ? ~~~~~~~~~ ? Latest release tarball of GCC ? I have also included Gregor Richards' patch set[1] to build ? GCC 5.3 against musl. These are more up to date than the ? patches in the musl-cross-make project which target GCC 5.2.0. ? GMP 4.3.2 ? ~~~~~~~~~ ? The version of GMP used on the gcc infrastructure page[2], we ? would use the latest version, which is 6.1.0, except that we ? encounter errors when cross building the native compiler for ? the target. These exact errors are discussed on the gmp-bugs ? list in this thread[3]. ? For this older package, we required an update of config.sub ? and config.guess in order to recognize the -linux-musl* triples, ? this is introduced in the form of a patch in the sources/patches ? directory. ? MPC 1.0.3 ? ~~~~~~~~~ ? Latest release tarball of MPC. ? MPFR 3.1.3 ? ~~~~~~~~~~ ? Latest release tarball of MPFR. ? Patches updating config.sub & config.guess ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ? The config.sub & config.guess needed to be updated for make, bash and ? distcc in order to compile with the -linux-musl* host triples. ? This should not effect builds using the older toolchain using GCC ? 4.2.1, it merely updates these packages to recognize the new triple ? at build time. ? Note that config.sub & config.guess are under GPLv3 but include an ? exception in the license that: ????"you may include it under the same distribution ?????terms that you use for the rest of that program" ? As an additional permission under section 7 of GPLv3. Host Tool Changes ~~~~~~~~~~~~~~~~~ To build gcc 5.3, we now require: ? o System installed c++ compiler ????GCC now is partly written in C++ ? o System installed ranlib ????Without this, we encounter problems building gcc, particularly when ????linking GCC libiberty.a in the final native compiler. Overview how we build GCC 5.3 compared to 4.2.1 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ? o Binutils takes the new flag --enable-install-libiberty, which was ????implied in older versions. ????This is currently insubstantial and we could do without installing ????libiberty here. We only install libiberty for the sake of building ????elf2flt for the sh2eb target, which is currently only supported ????with uClibc, which we do not build with GCC 5.3. ????This change was kept to ease transition to GCC 5.3 once we can ????supported it, although it may be useless. ? o We ignore NO_CPLUSPLUS when building the new toolchain, GCC 5.3 ????requires C++ to build itself and even pass it's own configure ????scripts. ? o The first stage compiler (or 'simple' cross compiler) is built ????in a different order: ????- Build GCC with only support for the C language ????- Build libc ????- Build GCC again, this time with C++ support ????This is because you need libc in order to build the libstdc++ ????runtime. And you cannot get away with not building C++ at this ????stage of course, because you also need C++ to compile gcc in the ????full canadian cross compiler and native compiler. ? o GCC's new dependencies, GMP, MPC and MPFR are build directly in the ????gcc build directory, this makes the whole build script a little ????simpler because we dont have to care about configuring and staging ????these libraries by hand as they are build as GCC modules. ????To avoid building these twice, we install it the first time around ????before building libc and pass --with-gmp etc on the second pass. Caveats ~~~~~~~ The patch set is relatively clean, but there are some dirty hacks and oddities, I will try to specify them all here. ? o We install musl twice ????When building with GCC 5.3, we install musl twice because our ????ccwrap program expects musl in one location while the gcc build ????itself expects to find it in another location. ????This does not break anything but is redundant and dirty and ????is relatively easy to fix. ? o Redundant builds of gmp, mpfr and mpc ????I did not want to write individual build recipies and try to get ????all the configure flags right everywhere, and thought it prudent to ????allow GCC's toplevel configure script to configure those in it's ????subdirectory as GCC should know how to do that better than us. ????The downside is that since we necessarily build GCC twice in the ????simple-cross-compiler stage (where a libc is required to build C++ ????support in the second pass), we end up building these libraries ????twice as well. ????I have tried issuing a make -C ${subdir} install in the first pass ????and reusing them in the second pass by passing --with-gmp etc ????during that second pass, and while this satisfies the configure ????script it also breaks the build for some reason. ????It could be the only sane fix is to build them completely ????separately. ? o The target triplets may have bugs right now. ????In order to build GCC 5.3 against musl for any arch, it is ????necessary to specify the target triplet ending in -musl* ????The approach I've used to solve this is a little hack in ????functions.sh which specifies -linux-gnu as the default and ????substitutes 's/gnu/musl' in the specific case that we are building ????GCC 5.3 against musl. ????The thinking is that in the targets, if a specific CROSS_TARGET is ????specified, it should absolutely specify the trailing '-gnu' and let ????the build scripts decide if it is indeed -gnu or -musl. ????A cleaner fix might be to mandate that if the targets specify a ????CROSS_TARGET, it use a special suffix, so for instance in ????sources/targets/armv5l we could specify: ?????????????armv5l-unknown-linux-LIBC-SUFFIXeabi ????And allow functions.sh to substitute LIBC-SUFFIX depending on which ????libc happens to be chosen for the given build. ????There could be various approaches to address this in a cleaner way. [0]:https://github.com/richfelker/musl-cross-make [1]:https://github.com/GregorR/musl-gcc-patches [2]:ftp://gcc.gnu.org/pub/gcc/infrastructure/ [3]:https://gmplib.org/list-archives/gmp-bugs/2015-December/003848.html -------------- next part -------------- A non-text attachment was scrubbed... Name: aboriginal-gcc-5.3-support.tar.xz Type: application/x-xz-compressed-tar Size: 62144 bytes Desc: not available URL: From tristan.vanberkom at codethink.co.uk Thu Jan 21 14:20:05 2016 From: tristan.vanberkom at codethink.co.uk (Tristan Van Berkom) Date: Thu, 21 Jan 2016 23:20:05 +0900 Subject: [Aboriginal] Proposed patches to support modern toolchain In-Reply-To: <1453302028.25793.51.camel@codethink.co.uk> References: <1453302028.25793.51.camel@codethink.co.uk> Message-ID: <1453386005.25793.69.camel@codethink.co.uk> Hi, It seems there was an error with the last patchset and I had not handled the case of dual-patchset-for-same-package-name properly, so the regular GPLv2 only toolchain was failing to build because of this. I am attaching another tarball which fixes this problem, so this time you can really build either toolchain without issue. Also pushed a 'patches-v2' branch to the github in case you want to view the patchset easily online (or try it out), they can be seen here:? ? ??https://github.com/gtristan/aboriginal-gcc-5.3-support/commits/patc hes-v2 Note: This entire branch is exactly the patchset, not the previous patchset with additional patches over patches - also, note that this github was put online for the sole purpose of sharing this work easily at this stage. Also, I did something embarrassing in the last email and contradicted myself, so for posterity I will clarify that here: On Thu, 2016-01-21 at 00:00 +0900, Tristan Van Berkom wrote: [...] Overview how we build GCC 5.3 compared to 4.2.1 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [...] > ? o GCC's new dependencies, GMP, MPC and MPFR are build directly in > the > ????gcc build directory, this makes the whole build script a little > ????simpler because we dont have to care about configuring and > staging > ????these libraries by hand as they are build as GCC modules. > > ????To avoid building these twice, we install it the first time > around > ????before building libc and pass --with-gmp etc on the second pass. This is untrue, I tried this but it failed and I forgot to remove this from my own notes. [...] > ????The downside is that since we necessarily build GCC twice in the > ????simple-cross-compiler stage (where a libc is required to build > C++ > ????support in the second pass), we end up building these libraries > ????twice as well. > > ????I have tried issuing a make -C ${subdir} install in the first > pass > ????and reusing them in the second pass by passing --with-gmp etc > ????during that second pass, and while this satisfies the configure > ????script it also breaks the build for some reason. > > ????It could be the only sane fix is to build them completely > ????separately. This part, which contradicts the first, is of course true :) Sorry for that confusion. Best Regards, ? ? -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: aboriginal-gcc-5.3-support-v2.tar.xz Type: application/x-xz-compressed-tar Size: 62100 bytes Desc: not available URL: From rob at landley.net Fri Jan 22 17:01:31 2016 From: rob at landley.net (Rob Landley) Date: Fri, 22 Jan 2016 11:01:31 -0600 Subject: [Aboriginal] Unable to use gcc inside chroot of latest aboriginal. In-Reply-To: References: <5691737F.8070805@gmail.com> <5692FEAA.10104@landley.net> <569A5A40.9020308@gmail.com> <569B3A6E.7090200@landley.net> Message-ID: <56A2606B.2070909@landley.net> 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 From rob at landley.net Sat Jan 23 05:48:13 2016 From: rob at landley.net (Rob Landley) Date: Fri, 22 Jan 2016 23:48:13 -0600 Subject: [Aboriginal] Mailing list archives "fixed". Message-ID: <56A3141D.60401@landley.net> On the bright side, Dreamhost restored most of 2015 to the web archive(s)! (Yay!) On the downside, when swapping out to the more recent backup they deleted the messages _since_ then. So the second half of december and up till this week in January are missing now. But hey, progress! Rob From rob at landley.net Sat Jan 23 06:44:40 2016 From: rob at landley.net (Rob Landley) Date: Sat, 23 Jan 2016 00:44:40 -0600 Subject: [Aboriginal] Migrating to git. Message-ID: <56A32158.3080505@landley.net> FYI http://github.com/landley/aboriginal is up, a straight conversion of the current hg repo. I'll probably cut the next release from that. Rob