From vda.linux at googlemail.com Mon Jan 30 21:48:26 2017 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Mon, 30 Jan 2017 22:48:26 +0100 Subject: [Aboriginal] Latest cross-compiler-x86_64 stopped working as /usr/bin/x86-64-gcc symlink Message-ID: Hi Rob, Needing to test some musl glob() issues, today I downloaded http://landley.net/aboriginal/downloads/binaries/cross-compiler-x86_64.tar.gz I unpacked it into /some/directory, then made it available system-wide: ln -sf /some/directory/bin/* /usr/bin This used to work: I have a much older installation in /some/fwl_x_glibc_x8664_uclibc_x8664-0.9.11, and for it this procedure works. After it: $ x86_64-gcc rawcc: no input files That is, it found /some/fwl*/x86_64-unknown-linux/bin/rawcc But for the one I downloaded today, it does not work: $ x86_64-gcc rawcc: No such file or directory It appears it does not like being a symlink: $ /usr/bin/x86_64-gcc rawcc: No such file or directory // still no go $ ls -l /usr/bin/x86_64-gcc lrwxrwxrwx 1 root root 55 Jan 30 22:43 /usr/bin/x86_64-gcc -> /usr/app/aboriginal-20170130-cross-x8664/bin/x86_64-gcc $ /usr/app/aboriginal-20170130-cross-x8664/bin/x86_64-gcc rawcc: no input files // OK, now it works From rob at landley.net Tue Jan 31 03:13:10 2017 From: rob at landley.net (Rob Landley) Date: Mon, 30 Jan 2017 21:13:10 -0600 Subject: [Aboriginal] Latest cross-compiler-x86_64 stopped working as /usr/bin/x86-64-gcc symlink In-Reply-To: References: Message-ID: On 01/30/2017 03:48 PM, Denys Vlasenko wrote: > Hi Rob, > > Needing to test some musl glob() issues, today I downloaded > > http://landley.net/aboriginal/downloads/binaries/cross-compiler-x86_64.tar.gz Timing. [1] Aboriginal Linux is mothballed, and is being replaced by two projects: toolchain: https://github.com/musl-cross-make [2] filesystem: https://github.com/landley/mkroot And I've giving a tutorial based on the new stuff at ELC next month: https://openiotelcna2017.sched.com/event/9Ith/tutorial-building-the-simplest-possible-linux-system-rob-landley-se-instrumentscom The reasons I discontinued the old one last year are described here: http://lists.landley.net/pipermail/aboriginal-landley.net/2016-May/002567.html The announcement of the replacement was here: http://lists.landley.net/pipermail/aboriginal-landley.net/2016-November/002591.html And my goals going forward (turning Android into a self-hosting development environment out of the box) are described here (with links to a long writeup of why, and an hour long talk I gave on the subject): http://landley.net/toybox/about.html Meanwhile, Android has already weaned itself off of gcc and gone to LLVM, as described by Elliott Hughes (Android's Base OS maintainer) here: http://lists.landley.net/pipermail/toybox-landley.net/2016-December/008795.html Who said (when we were discussing building the kernel with an llvm toolchain, such as the one shipped in the Android NDK): > i think the "we aren't using gcc any more, and 4.9 was the last > version we'll update to, and we're not maintaining that any more > either" message is pretty well understood at this point, so several > different groups are independently working on this, for different > architectures. the google folks seem to have gotten further than the > linaro folks judging by conversation at plumbers this year, but i > think it's clear to everyone that it's a priority at this point. Here's a post from Elliott (who maintains bionic and toolbox) about replacing the rest of toolbox with toybox: http://lists.landley.net/pipermail/toybox-landley.net/2016-June/008484.html And here's the most recent time I discussed my longer-term plans with Elliott in public: http://lists.landley.net/pipermail/toybox-landley.net/2016-December/008779.html (Google hasn't explicitly agreed to these plans, but they know about them and are regularly merging my code.) Aboriginal Linux's airlock step has already moved into toybox (make install_airlock), my new root-filesystem build is mkroot and I'm slowly weaning it off of busybox (I need to finish toybox tar, gzip compression side, unxz, route, wget, ping, vi, and sh), and I was working on a kernel build script over the weekend to do qemu test images in. Google's really big into regression testing, so if I present them with a test infrastructure using mkroot they'll probably start playing with it... Part of the reason this bubbled to the top of my todo list again is I talked with a bunch of people about it at linux.conf.au last week, and they generally seemed excited about the idea. I've been hugely distracted by $DAYJOB stuff for the past 6 months but that may finally be working its way through... (Fingers crossed.) In addition to the GPLv3 issues, Aboriginal Linux was way too complex to help much with the upcoming AOSP rewrite: peeling AOSP apart into orthogonal layers (so you can build a "base OS" for an embedded iot/drone/pi without downloading tens of gigabytes of source code first) requires a much simpler approach. Given that Aboriginal is something like the third reboot and fourth name for the project anyway: https://landley.net/aboriginal/history.html If you need a new toolchain for busybox testing, try musl-cross-make. Here's some test scripts I used to build it for lots of different targets over the weekend: http://landley.net/temp/ I did a "git clone https://github.com/richfelker/musl-cross-make", dropped those two scripts in the directory above it, and ran "../all.sh". (It's in the directory above because I got tired of losing updates to "git clean -fdx && git checkout -f", it should be easy enough to strip that part out if you don't accidentally do that a lot. :) I have no idea if the resulting toolchains actually do what I want yet, I'm still testing them. (Older versions did but that was 6 months ago and the build scripts were different.) A couple of architectures I tried (like cortex-m) didn't build, and there's no support for a few of the old ones aboriginal did yet (like sparc). But Rich is pretty good about responding to feedback. :) Rob [1] I spent a couple hours today writing up a eulogy for the project to post on the news page. I'm about half done. The tl;dr is given a choice between shipping a GPLv3 binary and ending the project, it was an easy decision. And thus the project ended. [2] Eventually I want the Android NDK llvm toolchain to work for mkroot too, which means it needs to build toybox defconfig. See the long thread most recently starting at http://lists.landley.net/pipermail/toybox-landley.net/2016-December/008767.html where Elliott's fixing up the NDK headers to it can build more of toybox. See also http://lists.landley.net/pipermail/toybox-landley.net/2016-December/008772.html in that thread for the difference between "NDK" and "Platform", I.E. why a toybox built with the NDK can't do everything toybox built with AOSP can. (Because the NDK doesn't have all the libraries and it needs selinux annotation to do its job. My current plan for self-hosting is to set up a posix container using minijail (https://lwn.net/Articles/700557/) you can chroot into and run builds under, but we'll see how it goes as we get closer.)