From patrick at gentoo.org Thu Dec 5 10:48:55 2013 From: patrick at gentoo.org (Patrick Lauer) Date: Thu, 05 Dec 2013 18:48:55 +0800 Subject: [Aboriginal] Missing 1.2.6 tarball and a small typo fix Message-ID: <52A05A17.2060705@gentoo.org> The tarball for 1.2.6 is absent in the http://landley.net/aboriginal/downloads/ folder. Makes fetching a bit more tedious ;) And a small unrelated fix: Location has changed / is wrong, much more fun with correct path --- aboriginal-1.2.5/README 2013-09-12 17:21:16.000000000 +0800 +++ aboriginal-f641160e79ea/README 2013-12-05 11:52:37.746322622 +0800 @@ -121,7 +121,7 @@ To build every supported target simultaneously (in parallel, using around 2 gigabytes of ram and maybe 20 gigabytes of disk space): - FORK=1 sources/more/buildall.sh + FORK=1 more/buildall.sh The file "configure" contains several environment variables you can set to control the behavior of Aboriginal Linux, and has comments documenting what 1386240535.0 From patrick at gentoo.org Sat Dec 7 00:54:04 2013 From: patrick at gentoo.org (Patrick Lauer) Date: Sat, 07 Dec 2013 08:54:04 +0800 Subject: [Aboriginal] Failures with 1.2.6 Message-ID: <52A271AC.3090404@gentoo.org> So again I'm testing the new release. One compile failure for armv4eb: STRIP -x -R .note -R .comment librt/librt_so.a STRIP -x -R .note -R .comment libc/libc_so.a make[1]: 'lib/ld-uClibc.so' is up to date. LD libuClibc-0.9.33.2.so libc/libc_so.a(close.oS):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0' collect2: ld returned 1 exit status libc/Makefile.in:64: recipe for target 'lib/libc.so' failed make: *** [lib/libc.so] Error 1 Exiting due to errors (armv4eb simple-cross-compiler uClibc) mips64 still not booting: VFS: Mounted root (squashfs filesystem) readonly on device 3:0. Freeing YAMON memory: 956k freed Freeing unused kernel memory: 204K (ffffffff8047d000 - ffffffff804b0000) Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a Rebooting in 1 seconds.. And sparc still having compiler problems: (sparc:1) /home # ^[[67;19Rgcc -s /usr/src/thread-hello2.c -lpthread -o /tmp/hello (sparc:1) /home # ^[[67;19R/tmp/hello /tmp/hello: symbol '__gcc_personality_v0': can't handle reloc type 0x17 (sparc:1) /home # ^[[67;19Rexit sd 0:0:0:0: [sda] Synchronizing SCSI cache reboot: Restarting system I also saw one transient failure with the x86_64 target, but couldn't reproduce it (crash on shutdown). All tests done on x86_64 and qemu-1.6.1 1386377644.0 From rob at landley.net Sat Dec 7 18:57:31 2013 From: rob at landley.net (Rob Landley) Date: Sat, 07 Dec 2013 12:57:31 -0600 Subject: [Aboriginal] toolchain placement options In-Reply-To: <52968C7A.7010305@gentoo.org> (from patrick@gentoo.org on Wed Nov 27 18:21:14 2013) Message-ID: <1386442651.1974.316@driftwood> On 11/27/2013 06:21:14 PM, Patrick Lauer wrote: > On 11/28/2013 06:51 AM, Rob Landley wrote: > >> I guess if you are not planning to develop Aboriginal in direction > of a > >> flexible build system this is fine by me. > > > > I'm not turning it into a full-fledged distro. what I want to do is > > create bootstrap images for distros, so you can do a > debian-boostrap and > > gentoo-bootstrap and fedora-bootstrap and so on that create a chroot > > within which their build tools will run to add more packages, > building > > them from source and loading them into their repository on whatever > the > > host happens to be. So if you want to create "slackware on sh4", > you can > > do so. > > > > Alas, that turns out to be a big job (gentoo assumes it's building > under > > gentoo, _and_ every ebuild file in portage is annotated with the > > complete list of every target it's allowed to run on, so adding a > new > > target to the portage tree requires touching just about every ebuild > > file in the tree because they weren't THINKING...) > > Let me just disagree with you ;) Happens a lot. :) > There's a very reasonable assumption that things will fail on a new > architecture, so it makes more sense to whitelist things when they > have > been tested, patched and beaten into submission. So a package that works on 8 architectures already is obviously going to blow up on a 9th. If you have 16,000 packages and 400 of them are going to blow up on a new architecture, (of which 300 of that means you need to fix your toolchain and uClibc and not touch anything in the package), the logical thing to do is change the ebuilds of the 98% that didn't have a problem to say "yup, didn't have a problem". What the hexagon guys did at Qualcomm was have the gentoo hexagon architecture pretend to be a derivative of the gentoo x86 architecture to globally disable that craziness. (And then not bother to push anything back upstream to gentoo because that was such a gross hack and they were never going to bother to do it the way you wanted.) > Blacklisting things is not good when you want everything to build, > because it's hard to get enough test coverage (build everything on > HPPA? > You funny person ...) and to keep the blacklist updated for new > versions > (Who would have guessed that Java/Icedtea still doesn't build on > SPARC?) A) The point of this project is so you _can_ natively regression test builds, under qemu or on real hardware. B) How does failing closed instead of failing open change the "we haven't got a scalable test environment for this architecture"? > (On a sidenote, if you are in a I-Don't-Care mode you can just tell > portage to accept anything - or that anything that works on x86 should > be ok too. But that's Not A Good Idea :) ) It gets things done, and then it means you will never try to interface with upstream because it's not their way of doing it. (It also means your coverage pass hits cases where it tries to compile x86 assembly packages for x11 and such, so the gentoo based build system is making more work for you and you eventually abandon it and switch to Beyond Linux from Scratch instead. Or at least that's what hexagon did back in 2010.) > And luckily your "Gentoo needs Gentoo" claim has been undermined over > the years, first by Gentoo Prefix (which even works on win32 and other > mad platforms) and lately by RAP ("RAP ain't Prefix") which started as > an experiment on Android ( > http://wiki.gentoo.org/wiki/Project:Android/build ) I'll give this fifth approach a try, sure. Rob 1386442651.0 From rob at landley.net Mon Dec 16 00:53:18 2013 From: rob at landley.net (Rob Landley) Date: Sun, 15 Dec 2013 18:53:18 -0600 Subject: [Aboriginal] Failures with 1.2.6 In-Reply-To: <52A271AC.3090404@gentoo.org> References: <52A271AC.3090404@gentoo.org> Message-ID: <52AE4EFE.1060302@landley.net> New email client! Still setting filters up, and I've got a chunk of old email in the old one to get through still... On 12/06/13 18:54, Patrick Lauer wrote: > So again I'm testing the new release. One compile failure for armv4eb: > > STRIP -x -R .note -R .comment librt/librt_so.a > STRIP -x -R .note -R .comment libc/libc_so.a > make[1]: 'lib/ld-uClibc.so' is up to date. > LD libuClibc-0.9.33.2.so > libc/libc_so.a(close.oS):(.ARM.exidx+0x0): undefined reference to > `__aeabi_unwind_cpp_pr0' Huh, that target's not eabi, it's oabi. It's armv4l done big endian. Odd... > collect2: ld returned 1 exit status > libc/Makefile.in:64: recipe for target 'lib/libc.so' failed > make: *** [lib/libc.so] Error 1 > > Exiting due to errors (armv4eb simple-cross-compiler uClibc) Alas, arm big endian never quite worked under qemu. This is a QEMU limitation, something to do with I/O translation. Last I heard it still wasn't quite there: http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg03449.html That board emulation was added because somebody was testing on actual arm big endian hardware, and then they went away again. Somebody else was testing on an armv5eb but they went away again too. I never had a test environment for this. I note that building a kernel for this requires expanding the kconfig patch stuff to make the versatile board yet more versatile. I have a 2/3 finished patch around here somewhere, but got to the point where it wouldn't boot on qemu because of the above "qemu never implemented an emulation with all the switches set the right way" issue. I admit that "known not to work" targets don't get as much attention from me as they should, but... I can't test 'em. > mips64 still not booting: > > VFS: Mounted root (squashfs filesystem) readonly on device 3:0. > Freeing YAMON memory: 956k freed > Freeing unused kernel memory: 204K (ffffffff8047d000 - ffffffff804b0000) > Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000a > > Rebooting in 1 seconds.. My very vague understanding of mips64 is: Long ago, somebody made the first 64 bit mips workstation (possibly early irix stuff before SGI wandered away from workstations), and that's what I was originaly targeting with that. It was almost immediately abandoned, and bit-rotted badly in the kernel because it never sold well to begin with and then nobody used it for years. More recently, everything's going 64 bit and that includes mips, so they did a _different_ 64 bit implementation. I'm not sure what changed, but I need to retarget this with a different configuration somehow. There's also a mips32 target that differs from mips-r4k, which I'd like to add support for. Unfortunately, I don't know enough about mips. Happy for somebody who does to point me in the right direction on either one. I can dig into mips64 and try to get it working again, but I'd like more information about what I should be targeting there. Specifically, in Linux is CONFIG_CPU_MIPS64_R1=y still right, and in uClibc is CONFIG_MIPS_N64_ABI=y and CONFIG_MIPS_ISA_MIPS64=y still relevant? (I vaguely recall the N64 thing is old and busted...) > And sparc still having compiler problems: > (sparc:1) /home # ^[[67;19Rgcc -s /usr/src/thread-hello2.c -lpthread -o > /tmp/hello > (sparc:1) /home # ^[[67;19R/tmp/hello > > /tmp/hello: symbol '__gcc_personality_v0': can't handle reloc type 0x17 > (sparc:1) /home # ^[[67;19Rexit > sd 0:0:0:0: [sda] Synchronizing SCSI cache > reboot: Restarting system Odd, I've built the whole of linux from scratch under sparc. Now admittedly there's a problem with either the kernel or qemu that leads to qemu-system-sparc hanging if the host system is doing anything else. (Some sort of race condition where something doesn't happen fast enough and then never happens, or some such. I forget if it's spinning at 100% cpu or hung, haven't tracked it down...) Lemme try to reproduce this one. > I also saw one transient failure with the x86_64 target, but couldn't > reproduce it (crash on shutdown). I've seen that too, can't reproduce it either. I believe the qemu guys are aware of it, but more information's usually helpful... > All tests done on x86_64 and qemu-1.6.1 There's a new one out I need to poke at... Sorry, my big "catch up on everything" push ran into me coming down with a horrible cold December 2nd that lasted for TWO WEEKS. Still not entirely coherent, but recovered enough I'm starting to poke at stuff again. Thanks, Rob (Oh, PS. I tried your gentoo bootstrapping thing and it made it a largeish way before dying when it finally tried to build something against the new glibc. I think it was my toolchain wrapper screwing stuff up, I'm halfway through the rewrite to allow musl, I'll use this as a test case when I get back to that. Thanks for the pointer.) 1387155198.0 From rob at landley.net Mon Dec 16 03:01:20 2013 From: rob at landley.net (Rob Landley) Date: Sun, 15 Dec 2013 21:01:20 -0600 Subject: [Aboriginal] Failures with 1.2.6 In-Reply-To: <52A271AC.3090404@gentoo.org> References: <52A271AC.3090404@gentoo.org> Message-ID: <52AE6D00.50108@landley.net> On 12/06/13 18:54, Patrick Lauer wrote: > And sparc still having compiler problems: > (sparc:1) /home # ^[[67;19Rgcc -s /usr/src/thread-hello2.c -lpthread -o > /tmp/hello > (sparc:1) /home # ^[[67;19R/tmp/hello > > /tmp/hello: symbol '__gcc_personality_v0': can't handle reloc type 0x17 > (sparc:1) /home # ^[[67;19Rexit > sd 0:0:0:0: [sda] Synchronizing SCSI cache > reboot: Restarting system Type exit when done. (sparc:1) /home # gcc -lpthread /usr/src/thread-hello.c (sparc:1) /home # ./a.out Hello, world! (sparc:1) /home # That's a fresh clone from hg 1640, although the host is qemu-1.5.1 at the moment. Lemme build 1.6.1... Nope, behaved the same way. I'm not reproducing this. Rob 1387162880.0