From rob at landley.net Tue Oct 4 19:18:52 2011 From: rob at landley.net (Rob Landley) Date: Tue, 04 Oct 2011 14:18:52 -0500 Subject: [Aboriginal] 1.1 is out. Message-ID: <4E8B5C1C.4020506@landley.net> It now natively builds LFS 6.7 on 11 different targets. Details on the website, as usual. The gentoo-bootstrap.hdc effort is now funtoo-bootstrap.hdc, which is the version Daniel Robbins (founder of gentoo) is working on these days, so much easier for me to get questions answered. :) This time around was mostly just bugfixes. Switching on NPTL is still todo, but reasonably low-hanging fruit and I'll probably need it for funtoo anyway. Rob 1317755932.0 From rob at landley.net Tue Oct 4 20:04:11 2011 From: rob at landley.net (Rob Landley) Date: Tue, 04 Oct 2011 15:04:11 -0500 Subject: [Aboriginal] aboriginal In-Reply-To: <4E89019F.6050808@gmx.net> References: <4E7E0A79.6060609@gmx.net> <4E7EB7A5.2040907@landley.net> <4E7F4B15.3030803@gmx.net> <4E81C278.3020707@landley.net> <4E89019F.6050808@gmx.net> Message-ID: <4E8B66BB.6060106@landley.net> On 10/02/2011 07:28 PM, maillist-aboriginal at barfooze.de wrote: > On 09/27/2011 02:32 PM, Rob Landley wrote: >> On 09/25/2011 10:39 AM, maillist-aboriginal at barfooze.de wrote: >>> On 09/25/2011 07:09 AM, Rob Landley wrote: >>>> On 09/24/2011 11:51 AM, maillist-aboriginal at barfooze.de wrote: >>>>> hi, was playing around with aboriginal lately. >>>>> since i haven't seen you on #uclibc lately, i thought i'd just write a >>>>> mail... >>>> I'm on the road at the moment, with limited internet access. I get >>>> home >>>> the 27th. >>>> >>>>> i was wondering why gcc 4.2.1 has been chosen (i know that 4.2.4 is >>>>> the >>>>> last one that builds without dependency libraries) >>>> 4.2.1 was the last GPLv2 release. I've built newer ones, but don't >>>> distribute them. I'll probably check in a script to do so at some >>>> point, and add a config option for it. >>>> >>> hmm... what's the difficulty with GPL v3 if i may ask ? >> 1) It's not the license the Linux kernel is under, and is incompatible >> with the Linux kernel. > > hmm, didnt know that. is that only for binary distributions ? Pretty much all open source licenses only put conditions on binary distribution. Restricting source distribution means "you aren't remotely open source". That's why I've been pondering adding build scripts for more recent binutils/gcc versions, but not shipping the resulting binaries. (I wouldn't mind so much if they hadn't added mpfr and such and made the resulting builds _complete_different_. Even though they're just different versions of the same packages they don't build remotely the same way, because the FSF is crazy. So I'd have to maintain two sources/sections/{gcc,binutils}.sh build scripts for those packages, which seems silly.) > how is it possible that you can get livecd's like ubuntu that have also > GPLv3 stuff on em? The same way you can have the proprietary binary-only flash plugin on your livecd, that's "mere aggregation" according to the last paragraph of GPLv2 section 2: In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License. >> 2) The FSF is crazy and I don't trust them to enforce anything after >> they destroyed Linksys and chased Cisco out of the Linux business. >> (Cisco outsources all Linux work now so as not to get any FSF copyrights >> on them.) > >> Specifically, after what the FSF did to the Mepis distribution I know >> they go after individuals. (Mepis was an Ubuntu reskin that had >> officially partnered with Ubuntu, had press releases from both sides to >> that effect, and was relying on Ubuntu's upstream source repositories >> for all the packages they hadn't modified. The FSF sued the one >> full-time guy doing Mepis for not mirroring all those unmodified source >> packages. I can send you links if you like.) > hmm if thats true, that's pretty evil. That's what I thought, yes: http://lwn.net/Articles/193852/ http://landley.net/code/toybox/licenserant.html http://landley.net/notes-2008.html#13-12-2008 >> 3) GPLv3 is an incredibly tone deaf license out of touch with the >> development community: I had to point out to them that their >> anti-tivoization crap meant that burning the code into ROM was violation >> of the penultimate draft of the license. (They fixed _that_ one but it >> still implies that if I have a world of Warcraft account and the WOW >> servers run BusyBox I can demand root access to their servers to upgrade >> the version of busybox on it.) >> >> 4) GPLv3 had no reason to exist, nothing ever rendered GPLv2 >> unenforceable so triggering the "lifeboat clause" in >> GPLv2 was disingenuous at best. The license was created because the FSF >> had lost political relevance, and this was their only avenue to regain >> leverage over the larger community. >> >> 5) Bruce Fucking Perens drove me away from Busybox development by >> trolling the busybox list about GPLv3 conversion, when we'd already >> discussed it extensively and come to a decision on the 10-year old list >> he'd never bothered to post on in the list's entire history. >> >> 6) If somebody wants to use the Sun CDDL or OSI license they're welcome >> to, but I don't. It's yet more pointless license fragmentation pushed >> by zealots at the expense of the pragamatists, and I'm not interested. > yeah. the whole license stuff is pretty annoying. I thought so, yes. GPLv2 was 15 years old, well understood, and worked great. Linus Torvalds said "the linux kernel is under GPLv2 only" back in 2000: http://lkml.indiana.edu/hypermail/linux/kernel/0009.1/0096.html And explained his reasoning in later posts over the years, some of which are collected here from 2002: http://yarchive.net/comp/linux/gpl.html And that extended to a lot of the kernel-developer tools like udev. Then in 2006 (YEARS after the kernel locked down its license), the FSF quoted Darth Vader from The Empire Strikes Back, "I am altering the bargain, pray I don't alter it any further", and the Linux kernel developers went "When we said we were sticking with GPLv2 we meant it", the FSF guys said "you'll change", the Linux developers came out with a statement that they wouldn't: http://lwn.net/Articles/200422/ The FSF went ahead with v3 anyway, and fractured the community. Jeremy Allison went along with them switching the license on Samba, and then later publicly said he regretted doing so. A lot of projects (such as QEMU and BusyBox) had to stay GPLv2 only because they'd incorporated kernel code over the years... It's a mess, and it's entirely the FSF's fault. They are _insane_. I'll reply to the non-license stuff next message. Rob 1317758651.0 From rob at landley.net Tue Oct 4 20:32:24 2011 From: rob at landley.net (Rob Landley) Date: Tue, 04 Oct 2011 15:32:24 -0500 Subject: [Aboriginal] What's musl, anyway? (was: re: aboriginal) Message-ID: <4E8B6D58.5030103@landley.net> >>> i built both gcc-core-4.5.3 and 4.6.0 on sabotage linux which only has a >>> C compiler (since musl doesnt support C++ yet) >>> the link time optimization newer gcc's (4.5+) support is quite nice as >>> it allows to strip off unneeded functions without putting each function >>> into an own object file. >> So you mean it's like the --function-sections and --gc-sections options >> I've been using since 2005? >> > it's not the same, it seems lto can also abandon code inside functions > which is never invoked. Ok. Sounds like fun: better optimizer. > fact is, the binaries are much smaller as with the dead code elimination > flags. > also in my tests stuff was partially 50% faster than with -O3 alone. > so it's actually a pretty neat feature. Sounds like you're compiling badly written code, but you work with what you've got... >>> gcc 3.4.6 builds fine with 128 mb and no swap at all... >>> also it is relatively slim (i have a statically built one here which >>> fits into a 6MB tarball...) >>> maybe it would be the best if someone would fork it and add the new >>> inline stuff... >>> that way it could still be used to build recent kernels. >> I built linux 3.0 with gcc 4.2.1 and binutils 2.17 on a dozen >> architectures, worked for me. What are you referring to? >> > i was talking about gcc *3*. Ah, I missed that. There are arguments for supporting older toolchain versions, and arguments for supporting newer toolchain versions. Mostly I just want a working toolchain to bootstrap a target, and then you can natively build a new toolchain under that in things like lfs-bootstrap.hdc. > gcc 3.4.6 is a relatively nice compiler, builds with less than 128MB > RAM, a statical linked crosscompiler fits into a 6MB .xz file, > it's faster than gcc4, and has relatively good optimization, compared > to pcc or tcc. Compared to tcc Turbo C for DOS had relatively good optimization. The interesting thing that newer gcc versions give you is support for more targets. For example, armv7 showed up in gcc 4.3, which is the big incentive to support the newer one. Support for the xylinx microblaze would also be nice, since qemu has that now. Alpha and m68k compilers that don't die so often with internal compiler errors while cross compiling stuff would also be cool, although I the native versions of those compilers might be more stable. > the build time on my 3ghz machine is 5 minutes compared to 45 minutes > for gcc4.5 (without mpc/mpfr/gmp, who consume another 5 minutes alone) > only thing missing is the gnu99 inline stuff. apart from that it > compiles 99% of the code out there. It is indeed cool. But if I recall it couldn't do simple dead code elimination on arm, meaning busybox had a build break trying to link code out of .c files it hadn't bothered to compile because it knew they wouldn't be used. >>> all other packages in sabotage linux build just fine with it. >>> since pcc is full of bugs and has nearly no optimization at all its not >>> gonna be a real option anytime soon... >>> and clang is in C++ itself... >> Yup. There are some people gluing sparse to llvm, but again: llvm is >> c++. I want to glue sparse or tcc to qemu's tcg, but it's down my todo >> list a lot... >> > never heard about tcg. i'll read up on that one. There's a README in qemu's tcg subdirectory. See also http://127.0.0.1/qemu/2008-01-29.html#Feb_1,_2008_-_TCG >>>>> on a sidenote, i really missed having a gdb around... wonder if its >>>>> possible to supply a binary in the future ? >>>> That's been on my todo list for a while, just hasn't been near the top. >>>> 6.6 was the last GPLv2 release, I can look into adding that to the >>>> cross compiler and the gdbserver binary to the static target binaries >>>> list... >>>> >>> i guess a separate download such as strace would be even better. >> I'm working on it, but it's also a bit down my todo list... >> >> Rob >> > > i currently have an issue here with aboriginal: > a) fdisk -l says both (root and home) partitions don't have a valid > partition table. i wonder why? Because they don't. I created filesystem images and attached them to qemu virtual disks: /dev/hda - squashfs root filesystem (mounted on /) /dev/hdb - 2 gig writeable ext3 (mounted on /home by dev-environment.sh) /dev/hdc - build control image (mounted on /mnt by native-build.sh) I'm mounting /dev/hda not /dev/hda1. The whole unpartitioned device has its own block device, which can have a filesystem on it. (You can do this with real hardware too. Floppies were never partitioned. I have no idea why removable USB drives tend to be partitioned, I think it's windows brain damage.) Once upon a time I did create partitioned images: http://landley.net/code/mkhda.sh But it's extra work for no benefit, and it means you can't easily loopback mount them from the host. > b) after unpacking and configuring gmp-5.0.2, i have a symlink > "gmp-5.0.2/mpn/add_n.asm -> ../mpn/arm/add_n.asm" > the symlink target is a regular file, but the readlink syscall returns > ELOOP in errno. If the readlink syscall was broken then ls -l wouldn't be able to display symlinks. What code is calling the readlink() syscall and getting confused? Did you run it under strace? (The static-build.hdc control image builds that, I put binaries up at http;//landley.net/aboriginal/downloads/binaries/extras you can just wget, chmod +x, and use if it helps. I can't link you to a specific one because I don't remember which target you're building for.) > that prevents GMP (prerequisite for gcc 4.5) from building. The lfs-bootstrap.hdc control image builds the gmp from Linux From Scratch 6.7 under 11 different targets. That's version 5.0.1 so possibly something changed between that and 5.0.2, but I don't understand how you're having a system call failure? (How do you know it's a system call failure? There's context you're not explaining...) > i can load the file into vi, both using the symlink and the link target. > musl's readdir is just a one liner around the kernel syscall. Use strace to see what arguments it's passing to the syscall. > i couldnt reproduce that behaviour with a manually created symlink > according to the above scheme. > but it is reproducible by untaring gmp again and restarting the build. > i suspect that's either a filesystem or kernel bug. So the symlink is created corrupted? What version are you using? (The 1.1 release is using the ext4 driver for both ext3 and ext2, and if you're untarring into /home under dev-environment.sh then it's using the /dev/hdb image which should be ext3.) The previous (1.0.3) release was using the separate ext2 and ext3 drivers for the journaled and nonjournaled versions of the same filesystem, which was silly. I'm not using ext4 yet, but one unified driver for both of those is cool. Shame if it's buggy, but we can get it fixed if so... > any suggestions are welcome ;) More info, please. Rob 1317760344.0 From james_mcmechan at hotmail.com Wed Oct 5 16:57:33 2011 From: james_mcmechan at hotmail.com (James McMechan) Date: Wed, 5 Oct 2011 09:57:33 -0700 Subject: [Aboriginal] What's musl, anyway? (was: re: aboriginal) In-Reply-To: <4E8B6D58.5030103@landley.net> References: <4E8B6D58.5030103@landley.net> Message-ID: > Date: Tue, 4 Oct 2011 15:32:24 -0500 > From: rob at landley.net > To: aboriginal at lists.landley.net; maillist-aboriginal at barfooze.de > Subject: [Aboriginal] What's musl, anyway? (was: re: aboriginal) > > >>> i built both gcc-core-4.5.3 and 4.6.0 on sabotage linux which only has a > >>> C compiler (since musl doesnt support C++ yet) > >>> the link time optimization newer gcc's (4.5+) support is quite nice as > >>> it allows to strip off unneeded functions without putting each function > >>> into an own object file. > >> So you mean it's like the --function-sections and --gc-sections options > >> I've been using since 2005? > >> > > it's not the same, it seems lto can also abandon code inside functions > > which is never invoked. > > Ok. Sounds like fun: better optimizer. gcc 4.6 is much more aggressive, it will for example automatically inline functions and then silently eliminate them based on use of local var addresses. oddly it silently removed the containing function also, and the structure reference and call to spinlock in the kernel. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48623 > > fact is, the binaries are much smaller as with the dead code elimination > > flags. > > also in my tests stuff was partially 50% faster than with -O3 alone. > > so it's actually a pretty neat feature. > > Sounds like you're compiling badly written code, but you work with what > you've got... > > >>> gcc 3.4.6 builds fine with 128 mb and no swap at all... > >>> also it is relatively slim (i have a statically built one here which > >>> fits into a 6MB tarball...) > >>> maybe it would be the best if someone would fork it and add the new > >>> inline stuff... > >>> that way it could still be used to build recent kernels. > >> I built linux 3.0 with gcc 4.2.1 and binutils 2.17 on a dozen > >> architectures, worked for me. What are you referring to? > >> > > i was talking about gcc *3*. > > Ah, I missed that. > > There are arguments for supporting older toolchain versions, and > arguments for supporting newer toolchain versions. Mostly I just want a > working toolchain to bootstrap a target, and then you can natively build > a new toolchain under that in things like lfs-bootstrap.hdc. > > > gcc 3.4.6 is a relatively nice compiler, builds with less than 128MB > > RAM, a statical linked crosscompiler fits into a 6MB .xz file, > > it's faster than gcc4, and has relatively good optimization, compared > > to pcc or tcc. > > Compared to tcc Turbo C for DOS had relatively good optimization. tcc the turbo C from dos or tcc the tiny c compiler which you appear to be thinking of below (http://bellard.org/tcc). > The interesting thing that newer gcc versions give you is support for > more targets. For example, armv7 showed up in gcc 4.3, which is the big > incentive to support the newer one. Support for the xylinx microblaze > would also be nice, since qemu has that now. Alpha and m68k compilers > that don't die so often with internal compiler errors while cross > compiling stuff would also be cool, although I the native versions of > those compilers might be more stable. > > > the build time on my 3ghz machine is 5 minutes compared to 45 minutes > > for gcc4.5 (without mpc/mpfr/gmp, who consume another 5 minutes alone) > > only thing missing is the gnu99 inline stuff. apart from that it > > compiles 99% of the code out there. > > It is indeed cool. But if I recall it couldn't do simple dead code > elimination on arm, meaning busybox had a build break trying to link > code out of .c files it hadn't bothered to compile because it knew they > wouldn't be used. > > >>> all other packages in sabotage linux build just fine with it. > >>> since pcc is full of bugs and has nearly no optimization at all its not > >>> gonna be a real option anytime soon... > >>> and clang is in C++ itself... > >> Yup. There are some people gluing sparse to llvm, but again: llvm is > >> c++. I want to glue sparse or tcc to qemu's tcg, but it's down my todo > >> list a lot... > >> > > never heard about tcg. i'll read up on that one. > > There's a README in qemu's tcg subdirectory. See also > http://127.0.0.1/qemu/2008-01-29.html#Feb_1,_2008_-_TCG Err, Rob this appears to be a archive on your machine... http://landley.net/qemu/2008-01-29.html#Feb_1,_2008_-_TCG works is tcg better?, tcc also by Bellard has i386,x86_64,arm,c67? architectures I think, and so has code generators for the most common 3 cases. or it just the remaining arches like ppc32,ppc64,sparc32,sparc64?,mips32,mips64 sh4 that is the concern. it also lacks gcc -Ml,d option for running the compiler to find out what the code being compiled depends on, that was one of the things linux kernel and busybox need gcc for :( that at least would not be too hard to add but it seems sort of a waste to run the compiler to find out what files to compile later... > >>>>> on a sidenote, i really missed having a gdb around... wonder if its > >>>>> possible to supply a binary in the future ? > >>>> That's been on my todo list for a while, just hasn't been near the top. > >>>> 6.6 was the last GPLv2 release, I can look into adding that to the > >>>> cross compiler and the gdbserver binary to the static target binaries > >>>> list... > >>>> > >>> i guess a separate download such as strace would be even better. > >> I'm working on it, but it's also a bit down my todo list... > >> > >> Rob > >> > > > > i currently have an issue here with aboriginal: > > a) fdisk -l says both (root and home) partitions don't have a valid > > partition table. i wonder why? > > Because they don't. I created filesystem images and attached them to > qemu virtual disks: > > /dev/hda - squashfs root filesystem (mounted on /) > /dev/hdb - 2 gig writeable ext3 (mounted on /home by dev-environment.sh) > /dev/hdc - build control image (mounted on /mnt by native-build.sh) > > I'm mounting /dev/hda not /dev/hda1. The whole unpartitioned device has > its own block device, which can have a filesystem on it. (You can do > this with real hardware too. Floppies were never partitioned. I have > no idea why removable USB drives tend to be partitioned, I think it's > windows brain damage.) > > Once upon a time I did create partitioned images: > > http://landley.net/code/mkhda.sh > > But it's extra work for no benefit, and it means you can't easily > loopback mount them from the host. > > > b) after unpacking and configuring gmp-5.0.2, i have a symlink > > "gmp-5.0.2/mpn/add_n.asm -> ../mpn/arm/add_n.asm" > > the symlink target is a regular file, but the readlink syscall returns > > ELOOP in errno. This symlink is not present before configure, the style of ../mpn/arm is slightly odd. I would expect ./arm/add_n.asm to be simpler, even the x86_64 version mpn/add_n.asm -> ../mpn/x86_64/aors_n.asm is strange, why a symlink to a arch file of a different name?... The going up and then down the mpn directory may be hitting some oddness, though local ref symlinks usually work just fine. The ELOOP indicating too many symlinks in path usually only occurs when a symlink loop is found... Was it being built as part of the Aboriginal scripts or was it being built by hand? It seems to be part of a arm build since it is symlinked there. > If the readlink syscall was broken then ls -l wouldn't be able to > display symlinks. What code is calling the readlink() syscall and > getting confused? Did you run it under strace? (The static-build.hdc > control image builds that, I put binaries up at > http;//landley.net/aboriginal/downloads/binaries/extras you can just > wget, chmod +x, and use if it helps. I can't link you to a specific one > because I don't remember which target you're building for.) > > > that prevents GMP (prerequisite for gcc 4.5) from building. > > The lfs-bootstrap.hdc control image builds the gmp from Linux From > Scratch 6.7 under 11 different targets. That's version 5.0.1 so > possibly something changed between that and 5.0.2, but I don't > understand how you're having a system call failure? (How do you know > it's a system call failure? There's context you're not explaining...) > > > i can load the file into vi, both using the symlink and the link target. > > musl's readdir is just a one liner around the kernel syscall. > > Use strace to see what arguments it's passing to the syscall. > > > i couldnt reproduce that behaviour with a manually created symlink > > according to the above scheme. > > but it is reproducible by untaring gmp again and restarting the build. > > i suspect that's either a filesystem or kernel bug. > > So the symlink is created corrupted? > > What version are you using? (The 1.1 release is using the ext4 driver > for both ext3 and ext2, and if you're untarring into /home under > dev-environment.sh then it's using the /dev/hdb image which should be ext3.) > > The previous (1.0.3) release was using the separate ext2 and ext3 > drivers for the journaled and nonjournaled versions of the same > filesystem, which was silly. I'm not using ext4 yet, but one unified > driver for both of those is cool. Shame if it's buggy, but we can get > it fixed if so... > > > any suggestions are welcome ;) > > More info, please. > > Rob > _______________________________________________ > Aboriginal mailing list > Aboriginal at lists.landley.net > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net > Date: Tue, 4 Oct 2011 15:32:24 -0500 > From: rob at landley.net > To: aboriginal at lists.landley.net; maillist-aboriginal at barfooze.de > Subject: [Aboriginal] What's musl, anyway? (was: re: aboriginal) > > >>> i built both gcc-core-4.5.3 and 4.6.0 on sabotage linux which only has a > >>> C compiler (since musl doesnt support C++ yet) > >>> the link time optimization newer gcc's (4.5+) support is quite nice as > >>> it allows to strip off unneeded functions without putting each function > >>> into an own object file. > >> So you mean it's like the --function-sections and --gc-sections options > >> I've been using since 2005? > >> > > it's not the same, it seems lto can also abandon code inside functions > > which is never invoked. > > Ok. Sounds like fun: better optimizer. > > > fact is, the binaries are much smaller as with the dead code elimination > > flags. > > also in my tests stuff was partially 50% faster than with -O3 alone. > > so it's actually a pretty neat feature. > > Sounds like you're compiling badly written code, but you work with what > you've got... > > >>> gcc 3.4.6 builds fine with 128 mb and no swap at all... > >>> also it is relatively slim (i have a statically built one here which > >>> fits into a 6MB tarball...) > >>> maybe it would be the best if someone would fork it and add the new > >>> inline stuff... > >>> that way it could still be used to build recent kernels. > >> I built linux 3.0 with gcc 4.2.1 and binutils 2.17 on a dozen > >> architectures, worked for me. What are you referring to? > >> > > i was talking about gcc *3*. > > Ah, I missed that. > > There are arguments for supporting older toolchain versions, and > arguments for supporting newer toolchain versions. Mostly I just want a > working toolchain to bootstrap a target, and then you can natively build > a new toolchain under that in things like lfs-bootstrap.hdc. > > > gcc 3.4.6 is a relatively nice compiler, builds with less than 128MB > > RAM, a statical linked crosscompiler fits into a 6MB .xz file, > > it's faster than gcc4, and has relatively good optimization, compared > > to pcc or tcc. > > Compared to tcc Turbo C for DOS had relatively good optimization. > > The interesting thing that newer gcc versions give you is support for > more targets. For example, armv7 showed up in gcc 4.3, which is the big > incentive to support the newer one. Support for the xylinx microblaze > would also be nice, since qemu has that now. Alpha and m68k compilers > that don't die so often with internal compiler errors while cross > compiling stuff would also be cool, although I the native versions of > those compilers might be more stable. > > > the build time on my 3ghz machine is 5 minutes compared to 45 minutes > > for gcc4.5 (without mpc/mpfr/gmp, who consume another 5 minutes alone) > > only thing missing is the gnu99 inline stuff. apart from that it > > compiles 99% of the code out there. > > It is indeed cool. But if I recall it couldn't do simple dead code > elimination on arm, meaning busybox had a build break trying to link > code out of .c files it hadn't bothered to compile because it knew they > wouldn't be used. > > >>> all other packages in sabotage linux build just fine with it. > >>> since pcc is full of bugs and has nearly no optimization at all its not > >>> gonna be a real option anytime soon... > >>> and clang is in C++ itself... > >> Yup. There are some people gluing sparse to llvm, but again: llvm is > >> c++. I want to glue sparse or tcc to qemu's tcg, but it's down my todo > >> list a lot... > >> > > never heard about tcg. i'll read up on that one. > > There's a README in qemu's tcg subdirectory. See also > http://127.0.0.1/qemu/2008-01-29.html#Feb_1,_2008_-_TCG > > >>>>> on a sidenote, i really missed having a gdb around... wonder if its > >>>>> possible to supply a binary in the future ? > >>>> That's been on my todo list for a while, just hasn't been near the top. > >>>> 6.6 was the last GPLv2 release, I can look into adding that to the > >>>> cross compiler and the gdbserver binary to the static target binaries > >>>> list... > >>>> > >>> i guess a separate download such as strace would be even better. > >> I'm working on it, but it's also a bit down my todo list... > >> > >> Rob > >> > > > > i currently have an issue here with aboriginal: > > a) fdisk -l says both (root and home) partitions don't have a valid > > partition table. i wonder why? > > Because they don't. I created filesystem images and attached them to > qemu virtual disks: > > /dev/hda - squashfs root filesystem (mounted on /) > /dev/hdb - 2 gig writeable ext3 (mounted on /home by dev-environment.sh) > /dev/hdc - build control image (mounted on /mnt by native-build.sh) > > I'm mounting /dev/hda not /dev/hda1. The whole unpartitioned device has > its own block device, which can have a filesystem on it. (You can do > this with real hardware too. Floppies were never partitioned. I have > no idea why removable USB drives tend to be partitioned, I think it's > windows brain damage.) > > Once upon a time I did create partitioned images: > > http://landley.net/code/mkhda.sh > > But it's extra work for no benefit, and it means you can't easily > loopback mount them from the host. > > > b) after unpacking and configuring gmp-5.0.2, i have a symlink > > "gmp-5.0.2/mpn/add_n.asm -> ../mpn/arm/add_n.asm" > > the symlink target is a regular file, but the readlink syscall returns > > ELOOP in errno. > > If the readlink syscall was broken then ls -l wouldn't be able to > display symlinks. What code is calling the readlink() syscall and > getting confused? Did you run it under strace? (The static-build.hdc > control image builds that, I put binaries up at > http;//landley.net/aboriginal/downloads/binaries/extras you can just > wget, chmod +x, and use if it helps. I can't link you to a specific one > because I don't remember which target you're building for.) > > > that prevents GMP (prerequisite for gcc 4.5) from building. > > The lfs-bootstrap.hdc control image builds the gmp from Linux From > Scratch 6.7 under 11 different targets. That's version 5.0.1 so > possibly something changed between that and 5.0.2, but I don't > understand how you're having a system call failure? (How do you know > it's a system call failure? There's context you're not explaining...) > > > i can load the file into vi, both using the symlink and the link target. > > musl's readdir is just a one liner around the kernel syscall. > > Use strace to see what arguments it's passing to the syscall. > > > i couldnt reproduce that behaviour with a manually created symlink > > according to the above scheme. > > but it is reproducible by untaring gmp again and restarting the build. > > i suspect that's either a filesystem or kernel bug. > > So the symlink is created corrupted? > > What version are you using? (The 1.1 release is using the ext4 driver > for both ext3 and ext2, and if you're untarring into /home under > dev-environment.sh then it's using the /dev/hdb image which should be ext3.) > > The previous (1.0.3) release was using the separate ext2 and ext3 > drivers for the journaled and nonjournaled versions of the same > filesystem, which was silly. I'm not using ext4 yet, but one unified > driver for both of those is cool. Shame if it's buggy, but we can get > it fixed if so... > > > any suggestions are welcome ;) > > More info, please. > > 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 maillist-aboriginal at barfooze.de Wed Oct 5 22:21:31 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Thu, 06 Oct 2011 00:21:31 +0200 Subject: [Aboriginal] aboriginal In-Reply-To: <4E8B66BB.6060106@landley.net> References: <4E7E0A79.6060609@gmx.net> <4E7EB7A5.2040907@landley.net> <4E7F4B15.3030803@gmx.net> <4E81C278.3020707@landley.net> <4E89019F.6050808@gmx.net> <4E8B66BB.6060106@landley.net> Message-ID: <4E8CD86B.9010503@barfooze.de> On 10/04/2011 10:04 PM, Rob Landley wrote: > On 10/02/2011 07:28 PM, maillist-aboriginal at barfooze.de wrote: >> On 09/27/2011 02:32 PM, Rob Landley wrote: >>> On 09/25/2011 10:39 AM, maillist-aboriginal at barfooze.de wrote: >>>> On 09/25/2011 07:09 AM, Rob Landley wrote: >>>>> On 09/24/2011 11:51 AM, maillist-aboriginal at barfooze.de wrote: >>>>>> hi, was playing around with aboriginal lately. >>>>>> since i haven't seen you on #uclibc lately, i thought i'd just write a >>>>>> mail... >>>>> I'm on the road at the moment, with limited internet access. I get >>>>> home >>>>> the 27th. >>>>> >>>>>> i was wondering why gcc 4.2.1 has been chosen (i know that 4.2.4 is >>>>>> the >>>>>> last one that builds without dependency libraries) >>>>> 4.2.1 was the last GPLv2 release. I've built newer ones, but don't >>>>> distribute them. I'll probably check in a script to do so at some >>>>> point, and add a config option for it. >>>>> >>>> hmm... what's the difficulty with GPL v3 if i may ask ? >>> 1) It's not the license the Linux kernel is under, and is incompatible >>> with the Linux kernel. >> hmm, didnt know that. is that only for binary distributions ? > Pretty much all open source licenses only put conditions on binary > distribution. Restricting source distribution means "you aren't > remotely open source". hmm. that means you have to add a note to the linux distribution that a DVD containing the sources can be ordered at address xy. or you just put up a download which contains all the sources. that's slightly uncomfortable since it is more work, but not really a big problem, since you basically just have to publish your already existing build environment plus some tarballs. > That's why I've been pondering adding build scripts for more recent > binutils/gcc versions, but not shipping the resulting binaries. (I > wouldn't mind so much if they hadn't added mpfr and such and made the > resulting builds _complete_different_. Even though they're just > different versions of the same packages they don't build remotely the > same way, because the FSF is crazy. So I'd have to maintain two > sources/sections/{gcc,binutils}.sh build scripts for those packages, > which seems silly.) > >> how is it possible that you can get livecd's like ubuntu that have also >> GPLv3 stuff on em? > The same way you can have the proprietary binary-only flash plugin on > your livecd, that's "mere aggregation" according to the last paragraph > of GPLv2 section 2: > > In addition, mere aggregation of another work not based on the Program > with the Program (or with a work based on the Program) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License. > >>> 2) The FSF is crazy and I don't trust them to enforce anything after >>> they destroyed Linksys and chased Cisco out of the Linux business. >>> (Cisco outsources all Linux work now so as not to get any FSF copyrights >>> on them.) >>> Specifically, after what the FSF did to the Mepis distribution I know >>> they go after individuals. (Mepis was an Ubuntu reskin that had >>> officially partnered with Ubuntu, had press releases from both sides to >>> that effect, and was relying on Ubuntu's upstream source repositories >>> for all the packages they hadn't modified. The FSF sued the one >>> full-time guy doing Mepis for not mirroring all those unmodified source >>> packages. I can send you links if you like.) >> hmm if thats true, that's pretty evil. > That's what I thought, yes: > > http://lwn.net/Articles/193852/ > http://landley.net/code/toybox/licenserant.html > http://landley.net/notes-2008.html#13-12-2008 > i've read that all, but it doesn't seem unnecessarily cruel. a) both cases are about GPL 2 / LGPL 2, not GPL 3 b) in the case of the mepis distribution (which is commercially oriented) the guy obviously missed to provide proper build scripts to let the user easily change his code. i don't see any reference to a court trial or similar, it looks more as if the FSF just contacted the guy and told him to change his stuff, which he obviously did. c) the cisco case: it seems the FSF was trying to talk with cisco for about 2 years to get them to provide source and build scripts for every piece of GNU sw they used. since cisco didn't manage to do that, it was actually necessary to go to court, to prove that the GPL is not a farce but something to care about, even for big business. if cisco had followed the instructions received by the FSF, they had gotten away with the costs of one salary for the open source officer. additionally, i can still get linksys routers at the local computer store. so the linux business of cisco was not really destroyed... >>> 3) GPLv3 is an incredibly tone deaf license out of touch with the >>> development community: I had to point out to them that their >>> anti-tivoization crap meant that burning the code into ROM was violation >>> of the penultimate draft of the license. (They fixed _that_ one but it >>> still implies that if I have a world of Warcraft account and the WOW >>> servers run BusyBox I can demand root access to their servers to upgrade >>> the version of busybox on it.) >>> >>> 4) GPLv3 had no reason to exist, nothing ever rendered GPLv2 >>> unenforceable so triggering the "lifeboat clause" in >>> GPLv2 was disingenuous at best. The license was created because the FSF >>> had lost political relevance, and this was their only avenue to regain >>> leverage over the larger community. >>> >>> 5) Bruce Fucking Perens drove me away from Busybox development by >>> trolling the busybox list about GPLv3 conversion, when we'd already >>> discussed it extensively and come to a decision on the 10-year old list >>> he'd never bothered to post on in the list's entire history. >>> >>> 6) If somebody wants to use the Sun CDDL or OSI license they're welcome >>> to, but I don't. It's yet more pointless license fragmentation pushed >>> by zealots at the expense of the pragamatists, and I'm not interested. >> yeah. the whole license stuff is pretty annoying. > I thought so, yes. > > GPLv2 was 15 years old, well understood, and worked great. Linus > Torvalds said "the linux kernel is under GPLv2 only" back in 2000: > > http://lkml.indiana.edu/hypermail/linux/kernel/0009.1/0096.html > > And explained his reasoning in later posts over the years, some of which > are collected here from 2002: > > http://yarchive.net/comp/linux/gpl.html > > And that extended to a lot of the kernel-developer tools like udev. > > Then in 2006 (YEARS after the kernel locked down its license), the FSF > quoted Darth Vader from The Empire Strikes Back, "I am altering the > bargain, pray I don't alter it any further", and the Linux kernel > developers went "When we said we were sticking with GPLv2 we meant it", > the FSF guys said "you'll change", the Linux developers came out with a > statement that they wouldn't: > > http://lwn.net/Articles/200422/ well i guess switching to GPLv3 could have really pissed of the majority of corporate kernel investors (intel et al.), so that was never a real option... > The FSF went ahead with v3 anyway, and fractured the community. Jeremy > Allison went along with them switching the license on Samba, and then > later publicly said he regretted doing so. A lot of projects (such as > QEMU and BusyBox) had to stay GPLv2 only because they'd incorporated > kernel code over the years... > > It's a mess, and it's entirely the FSF's fault. They are _insane_. > > I'll reply to the non-license stuff next message. > > Rob > 1317853291.0 From maillist-aboriginal at barfooze.de Wed Oct 5 23:04:02 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Thu, 06 Oct 2011 01:04:02 +0200 Subject: [Aboriginal] What's musl, anyway? (was: re: aboriginal) In-Reply-To: <4E8B6D58.5030103@landley.net> References: <4E8B6D58.5030103@landley.net> Message-ID: <4E8CE262.3060808@barfooze.de> let me answer the question in the subject first: musl is a new libc for linux, which imo is exceptionally well made. according to my own experience its smaller, faster and more correct than uclibc. here is a comparison: http://www.etalabs.net/compare_libcs.html (it even has stuff which uclibc lacks, such as posix_spawn, which is a really handy function) musl has ARM support since the last release and i'm currently porting sabotage linux to build on that arch, using aboriginal as my build platform. there are a couple of issues (mostly the old binutils used by aboriginal, which don't go well together with musl's gcc wrapper, the lack of a debugger and the speed and memory restrictions of qemu), however i'm making progress... On 10/04/2011 10:32 PM, Rob Landley wrote: >>>> i built both gcc-core-4.5.3 and 4.6.0 on sabotage linux which only >>>> has a >>>> C compiler (since musl doesnt support C++ yet) >>>> the link time optimization newer gcc's (4.5+) support is quite nice as >>>> it allows to strip off unneeded functions without putting each >>>> function >>>> into an own object file. >>> So you mean it's like the --function-sections and --gc-sections options >>> I've been using since 2005? >>> >> it's not the same, it seems lto can also abandon code inside functions >> which is never invoked. > Ok. Sounds like fun: better optimizer. yeah, it's pretty neat, once you are past the build stage... >> fact is, the binaries are much smaller as with the dead code elimination >> flags. >> also in my tests stuff was partially 50% faster than with -O3 alone. >> so it's actually a pretty neat feature. > Sounds like you're compiling badly written code, but you work with what > you've got... > not really, i did test a couple of different selfwritten arraylist implementations. using the -flto -fwhole-program flags, i could see big speed and size differences, when all involved c-files where thrown at once onto the compiler, as opposed to just linking object files together. >>>> gcc 3.4.6 builds fine with 128 mb and no swap at all... >>>> also it is relatively slim (i have a statically built one here which >>>> fits into a 6MB tarball...) >>>> maybe it would be the best if someone would fork it and add the new >>>> inline stuff... >>>> that way it could still be used to build recent kernels. >>> I built linux 3.0 with gcc 4.2.1 and binutils 2.17 on a dozen >>> architectures, worked for metime. What are you referring to? >>> >> i was talking about gcc *3*. > Ah, I missed that. > > There are arguments for supporting older toolchain versions, and > arguments for supporting newer toolchain versions. Mostly I just want a > working toolchain to bootstrap a target, and then you can natively build > a new toolchain under that in things like lfs-bootstrap.hdc. > i actually think a handful of patches on the kernel source would suffice to still build a complete linux system using gcc 3. given the immense memory requirements when compiling gcc4.5+it could even be possible that gcc 3 is the only vital option. >> gcc 3.4.6 is a relatively nice compiler, builds with less than 128MB >> RAM, a statical linked crosscompiler fits into a 6MB .xz file, >> it's faster than gcc4, and has relatively good optimization, compared >> to pcc or tcc. > Compared to tcc Turbo C for DOS had relatively good optimization. > > The interesting thing that newer gcc versions give you is support for > more targets. For example, armv7 showed up in gcc 4.3, which is the big > incentive to support the newer one. Support for the xylinx microblaze > would also be nice, since qemu has that now. Alpha and m68k compilers > that don't die so often with internal compiler errors while cross > compiling stuff would also be cool, although I the native versions of > those compilers might be more stable. > indeed, the more targets, the better. however i've seen in gcc's changelog that in the last releases some old architectures have been removed... >> the build time on my 3ghz machine is 5 minutes compared to 45 minutes >> for gcc4.5 (without mpc/mpfr/gmp, who consume another 5 minutes alone) >> only thing missing is the gnu99 inline stuff. apart from that it >> compiles 99% of the code out there. > It is indeed cool. But if I recall it couldn't do simple dead code > elimination on arm, meaning busybox had a build break trying to link > code out of .c files it hadn't bothered to compile because it knew they > wouldn't be used. > yep, that's the tradeoff you have to make... features vs bloat :/ >>>> all other packages in sabotage linux build just fine with it. >>>> since pcc is full of bugs and has nearly no optimization at all its >>>> not >>>> gonna be a real option anytime soon... >>>> and clang is in C++ itself... >>> Yup. There are some people gluing sparse to llvm, but again: llvm is >>> c++. I want to glue sparse or tcc to qemu's tcg, but it's down my todo >>> list a lot... >>> >> never heard about tcg. i'll read up on that one. > There's a README in qemu's tcg subdirectory. See also > http://127.0.0.1/qemu/2008-01-29.html#Feb_1,_2008_-_TCG > thanks, that looks pretty interesting. the level of optimization done is tiny, though (no idea how much it was improved since then). >>>>>> on a sidenote, i really missed having a gdb around... wonder if its >>>>>> possible to supply a binary in the future ? >>>>> That's been on my todo list for a while, just hasn't been near the >>>>> top. >>>>> 6.6 was the last GPLv2 release, I can look into adding that to >>>>> the >>>>> cross compiler and the gdbserver binary to the static target binaries >>>>> list... >>>>> >>>> i guess a separate download such as strace would be even better. >>> I'm working on it, but it's also a bit down my todo list... >>> >>> Rob >>> >> i currently have an issue here with aboriginal: >> a) fdisk -l says both (root and home) partitions don't have a valid >> partition table. i wonder why? > Because they don't. I created filesystem images and attached them to > qemu virtual disks: > > /dev/hda - squashfs root filesystem (mounted on /) > /dev/hdb - 2 gig writeable ext3 (mounted on /home by dev-environment.sh) > /dev/hdc - build control image (mounted on /mnt by native-build.sh) > > I'm mounting /dev/hda not /dev/hda1. The whole unpartitioned device has > its own block device, which can have a filesystem on it. (You can do > this with real hardware too. Floppies were never partitioned. I have > no idea why removable USB drives tend to be partitioned, I think it's > windows brain damage.) > > Once upon a time I did create partitioned images: > > http://landley.net/code/mkhda.sh > > But it's extra work for no benefit, and it means you can't easily > loopback mount them from the host. > ah, good to know. thanks for clarification. >> b) after unpacking and configuring gmp-5.0.2, i have a symlink >> "gmp-5.0.2/mpn/add_n.asm -> ../mpn/arm/add_n.asm" >> the symlink target is a regular file, but the readlink syscall returns >> ELOOP in errno. > If the readlink syscall was broken then ls -l wouldn't be able to > display symlinks. What code is calling the readlink() syscall and > getting confused? Did you run it under strace? (The static-build.hdc > control image builds that, I put binaries up at > http;//landley.net/aboriginal/downloads/binaries/extras you can just > wget, chmod +x, and use if it helps. I can't link you to a specific one > because I don't remember which target you're building for.) > >> that prevents GMP (prerequisite for gcc 4.5) from building. > The lfs-bootstrap.hdc control image builds the gmp from Linux From > Scratch 6.7 under 11 different targets. That's version 5.0.1 so > possibly something changed between that and 5.0.2, but I don't > understand how you're having a system call failure? (How do you know > it's a system call failure? There's context you're not explaining...) > >> i can load the file into vi, both using the symlink and the link target. >> musl's readdir is just a one liner around the kernel syscall. > Use strace to see what arguments it's passing to the syscall. > yep, using strace i could hunt down the bug. i was previously inserting printf's into musl code and recompiling everytime due to a lacking debugger... not really used to that kind of debugging. getting a working statically compiled gdb for ARM is on the top of my TODO list. musl had fcntl.h with values from i386, which slightly differ from ARM, so the O_LARGEFILE of musl's open() was interpreted as O_NOFOLLOW from the kernel. was fixed yesterday by http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e6d765a8b1278e9e5f507638ccdec9fe40e52364 (that's also a nice thing about musl, i report the bug and 10 minutes later it is fixed, usually) >> i couldnt reproduce that behaviour with a manually created symlink >> according to the above scheme. >> but it is reproducible by untaring gmp again and restarting the build. >> i suspect that's either a filesystem or kernel bug. > So the symlink is created corrupted? > > What version are you using? (The 1.1 release is using the ext4 driver > for both ext3 and ext2, and if you're untarring into /home under > dev-environment.sh then it's using the /dev/hdb image which should be > ext3.) > > The previous (1.0.3) release was using the separate ext2 and ext3 > drivers for the journaled and nonjournaled versions of the same > filesystem, which was silly. I'm not using ext4 yet, but one unified > driver for both of those is cool. Shame if it's buggy, but we can get > it fixed if so... > >> any suggestions are welcome ;) > More info, please. > > Rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prazzb at gmail.com Thu Oct 6 14:18:25 2011 From: prazzb at gmail.com (prasanna balan) Date: Thu, 6 Oct 2011 19:48:25 +0530 Subject: [Aboriginal] Build error Message-ID: I tried building aboriginal 1.1.0 and it broke during uClibc++ native compiler...The last few lines of the build are as below: =============================================================================================== ln gcc i686-unknown-linux-gcc-tmp && \ mv -f i686-unknown-linux-gcc-tmp i686-unknown-linux-gcc ); \ fi make[1]: Leaving directory `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/build-gcc/gcc' cleanup build-gcc cleanup gcc-core === ccwrap (i686 native-compiler) === uClibc++ (i686 native-compiler) Snapshot 'uClibc++'... make -C extra/config conf make[1]: Entering directory `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config' make[1]: *** ../../.config: Is a directory. Stop. make[1]: Leaving directory `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config' make: *** [extra/config/conf] Error 2 Exiting due to errors (i686 native-compiler uClibc++) real 19m9.994s user 15m44.539s sys 1m58.504s ================================================================================================= Everything upto this point runs fine. I use slackware-x86 distro. Basically there's no folder named /extra/config/conf...thus make -C breaks..but then how did it build earlier...or is it something else.... prazzb 1317910705.0 From rob at landley.net Thu Oct 6 18:04:55 2011 From: rob at landley.net (Rob Landley) Date: Thu, 06 Oct 2011 13:04:55 -0500 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: References: <4E8B6D58.5030103@landley.net> Message-ID: <4E8DEDC7.3030801@landley.net> On 10/05/2011 11:57 AM, James McMechan wrote: >> > gcc 3.4.6 is a relatively nice compiler, builds with less than 128MB >> > RAM, a statical linked crosscompiler fits into a 6MB .xz file, >> > it's faster than gcc4, and has relatively good optimization, compared >> > to pcc or tcc. >> >> Compared to tcc Turbo C for DOS had relatively good optimization. > > tcc the turbo C from dos or tcc the tiny c compiler which you appear > to be thinking of below (http://bellard.org/tcc). I maintained a fork of that compiler for a couple years: http//landley.net/hg/tinycc They still mention it from the tcc web page and tinycc wikipedia articles, last I checked. Fabrice more or less forked qemu off of the older tcc project, and then that took over all his time the same way buildroot sucked away the uClibc developers and buried discussion on its mailing list until the project stagnated. I put a lot of effort into getting uClibc unsquashed over the past few years (creating the buildroot mailing list and kicking the discussion over there, more or less appointing the current uClibc maintainer by fiat, sometimes it's nice to have root access to a shared server...) I was sort of trying to do the same thing to tcc but all I managed to do was prompt Fabrice to hand maintainership over to a Windows developer, who has no interest (or expertise) in Linux, and has no clue to manage an open source project. But it's "official" so I closed down my fork and went off and did other things: http://landley.net/code/tinycc I still need to chop out tcc's preprocessor and hook it up so distcc is calling tcc -E instead of gcc -E, which might speed up distributed compiles under qemu quite a bit. (It's up there with making all the targets use emulated gigabit ethernet instead of crazy old 10baseT cards that are expensive to emulate, and letting the emulated boards allocate more than 256 megs for their physical memory.) I also still have vague plans to glue QEMU's Tiny Code Generator (tcg) to the back of either tcc's front end or sparse, I made some notes about this back in 2009: http://landley.net/code/tinycc/qcc/todo.txt http://landley.net/code/tinycc/qcc/commands.txt (I actually had a mailing list for it at one point, but it stalled when I got buried in other things and went away when I switched hosting providers.) >> > never heard about tcg. i'll read up on that one. >> >> There's a README in qemu's tcg subdirectory. See also >> http://127.0.0.1/qemu/2008-01-29.html#Feb_1,_2008_-_TCG > > Err, Rob this appears to be a archive on your machine... Heh, sorry. I have an apache instance running on loopback with a copy of my website, and I look stuff up locally and then rename it when posting the URL. I sometimes miss them. :) > http://landley.net/qemu/2008-01-29.html#Feb_1,_2008_-_TCG works > is tcg better? Very much so, yes. > tcc also by Bellard has i386,x86_64,arm,c67? architectures Fabrice Bellard is awesome: http://www.softwarequalityconnection.com/2011/03/fabrice-bellard-portrait-of-a-superproductive-programmer/ But he essentially abandoned tinycc in 2005, to spend his time on qemu. (As far as I can tell, QEMU happened when he started doing so multiple-backend cleanup on tcc and went "what if I had multiple front-ends as well, that could handle input other than C code, such as another target's assembly code", and he made a kickass dynamic translator, and the rest is history.) The arm and x86_64 targets happened after Fabrice left the project, and are not well integrated (or debugged). x86-64 is eclipsing i386 but arm didn't even have a libgcc.a replacement last I checked, they still told you to copy gcc's. Also, _which_ arm is that? armv4l, armv4tl, armv5l, armv6l, armv7l? The tcg code can do all that, plus both big and little endian, plus several different floating point variants, plus mips (several different processor variants, both endiannesses, both 32 and 64 bit), powerpc (ditto), cris, microblaze, lm32, sparc, s390, sh4, m68k, alpha, and more added all the time. If you look at the tinycc release history, there was a multi-year gap after 2005, and then a burst of effort in 2008 (when my fork spurred the original project back to life), and then it's got 2 and 1/2 years without a release since my fork stopped. An active project does attract additional developers, thus the arm code dated from the tail end of Fabrice's tenure (but I'm the one who integrated it and made it work), and the x86-64 code dated from the activity period my fork spurred (although it was written against the "original" version, and was kind of desperately overdue because the switchover to 64 bit PCs had happened 3 years earlier and I believe Intel had already stopped _making_ 32 bit chips by that point, for desktops and laptops, anyway). The thing to remember about tcc is that in 2004, Fabrice did tccboot: http://bellard.org/tcc/tccboot.html That used a modified 2.4 kernel, only building a carefully selected subset, and removing/rewriting features even from that which the compiler couldn't deal with at the time, plus totally skippping dealing with the makefiles at all. But the point is, it WORKED. (Still does, it's fun to boot the iso under qemu.) Keep in mind, tcc started as a JOKE in 2002 (http://bellard.org/otcc/) and 2 years later it was building the Linux kernel. Seven years have passed since that, and you can't even reproduce the old tccboot with the current code, let alone build anything more recent, let alone use tcc as an actually gcc replacement building a linux+uClibc+busybox bootable system. Any wonder why I want to leverage Fabrice's _newer_ design and the very active community he built around it? > I think, and so has code generators for the most common 3 cases. The arm target is almost completely unused, and tcc didn't run natively _on_arm_ due to alignment issues when I stopped my fork. (Perhaps they've fixed it since then, but I doubt they're even aware of the issue.) > or it just the remaining arches like > ppc32,ppc64,sparc32,sparc64?,mips32,mips64 > sh4 that is the concern. it also lacks gcc -Ml,d option for running the > compiler > to find out what the code being compiled depends on, that was one of the > things > linux kernel and busybox need gcc for :( I hadn't noticed. I got blocked by its lack of vararrays (c99 feature the kernel depends on) and dead code elimination (kernel and busybox both need it or you get link failures, again something turbo C for dos did back in the 80's) I was working to fix that, but compiling Linux packages is not on grischka's radar, he's a windows developer. And I got sick of competing with a zombie following me around and having to port all external contributions from their tree to mine, despite how far mind had diverged, and despite the majority of the work in that tree being ports of what I was doing... *shrug* >> Once upon a time I did create partitioned images: >> >> http://landley.net/code/mkhda.sh >> >> But it's extra work for no benefit, and it means you can't easily >> loopback mount them from the host. >> >> > b) after unpacking and configuring gmp-5.0.2, i have a symlink >> > "gmp-5.0.2/mpn/add_n.asm -> ../mpn/arm/add_n.asm" >> > the symlink target is a regular file, but the readlink syscall returns >> > ELOOP in errno. > > This symlink is not present before configure, the style of ../mpn/arm > is slightly odd. I would expect ./arm/add_n.asm to be simpler, > even the x86_64 version mpn/add_n.asm -> ../mpn/x86_64/aors_n.asm > is strange, why a symlink to a arch file of a different name?... > The going up and then down the mpn directory may be hitting some > oddness, though local ref symlinks usually work just fine. > The ELOOP indicating too many symlinks in path usually only occurs > when a symlink loop is found... > Was it being built as part of the Aboriginal scripts or was it being > built by hand? Presumably it's being built natively under the resulting system (probably running under QEMU). That's one of the central design ideas of Aboriginal Linux, "we cross compile so you don't have to": http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu Rob 1317924295.0 From rob at landley.net Thu Oct 6 19:22:23 2011 From: rob at landley.net (Rob Landley) Date: Thu, 06 Oct 2011 14:22:23 -0500 Subject: [Aboriginal] aboriginal In-Reply-To: <4E8CD86B.9010503@barfooze.de> References: <4E7E0A79.6060609@gmx.net> <4E7EB7A5.2040907@landley.net> <4E7F4B15.3030803@gmx.net> <4E81C278.3020707@landley.net> <4E89019F.6050808@gmx.net> <4E8B66BB.6060106@landley.net> <4E8CD86B.9010503@barfooze.de> Message-ID: <4E8DFFEF.2000404@landley.net> On 10/05/2011 05:21 PM, John Spencer wrote: > On 10/04/2011 10:04 PM, Rob Landley wrote: >> On 10/02/2011 07:28 PM, maillist-aboriginal at barfooze.de wrote: >>> On 09/27/2011 02:32 PM, Rob Landley wrote: >>>> On 09/25/2011 10:39 AM, maillist-aboriginal at barfooze.de wrote: >>>>> On 09/25/2011 07:09 AM, Rob Landley wrote: >>>>>> On 09/24/2011 11:51 AM, maillist-aboriginal at barfooze.de wrote: >>>>>>> hi, was playing around with aboriginal lately. >>>>>>> since i haven't seen you on #uclibc lately, i thought i'd just >>>>>>> write a >>>>>>> mail... >>>>>> I'm on the road at the moment, with limited internet access. I get >>>>>> home >>>>>> the 27th. >>>>>> >>>>>>> i was wondering why gcc 4.2.1 has been chosen (i know that 4.2.4 is >>>>>>> the >>>>>>> last one that builds without dependency libraries) >>>>>> 4.2.1 was the last GPLv2 release. I've built newer ones, but don't >>>>>> distribute them. I'll probably check in a script to do so at some >>>>>> point, and add a config option for it. >>>>>> >>>>> hmm... what's the difficulty with GPL v3 if i may ask ? >>>> 1) It's not the license the Linux kernel is under, and is incompatible >>>> with the Linux kernel. >>> hmm, didnt know that. is that only for binary distributions ? >> Pretty much all open source licenses only put conditions on binary >> distribution. Restricting source distribution means "you aren't >> remotely open source". > hmm. that means you have to add a note to the linux distribution that a > DVD containing the sources > can be ordered at address xy. or you just put up a download which > contains all the sources. > that's slightly uncomfortable since it is more work, but not really a > big problem, since you basically just have > to publish your already existing build environment plus some tarballs. Oh I'm mirroring all the gplv2 stuff (and possibly some bsd stuff) at http://landley.net/aboriginal/mirror I've spoken to Eben Moglen (co-author of both GPLv2 and GPLv3) about this when I visited the SFLC's office in New York (which was handling the busybox license enforcement lawsuits), and he _almost_ convinced me that GPLv3 wasn't worth opposing. But what he couldn't convince me was that it was actually required. The FSF did it as a giant ego trip, they trod all over the Linux community, and I am _NOT_ a GNU developer. I'm a Linux developer. The GNU/Linux/Dammit crusade is an attempt to write history; Linux was a reaction to Andrew Tanenbaum's Minix (and 0.0.1 was written under it), and has no more relationship to the gnu project than FreeBSD, Solaris, AIX, or MacOS X do. Computer history is a hobby of mine, and I wrote up some of the REAL history on this topic (as I understand it) last year: http://landley.net/notes-2010.html#17-07-2010 http://landley.net/notes-2010.html#19-07-2010 Linus used the FSF as a tools vendor in _exactly_ the same way the Sun developers did, but he didn't try to claim GNU/Solaris. (Even when Ian Murdoch got hired to do project Indiana, which was opensolaris with mostly FSF packages for the root filesystem!) That said, the third parties like Code Sourcery who actually write new code push that code upstream under the project's current license, and since the FSF successfully recaptured EGCS stuff like armv7 and microblaze support is either in external forks or only in newer versions of gcc/binutils after the gplv3 switch. And pcc and llvm/clang have a long way to go to build a workable Linux system even under x86... >>>> 2) The FSF is crazy and I don't trust them to enforce anything after >>>> they destroyed Linksys and chased Cisco out of the Linux business. >>>> (Cisco outsources all Linux work now so as not to get any FSF >>>> copyrights >>>> on them.) >>>> Specifically, after what the FSF did to the Mepis distribution I know >>>> they go after individuals. (Mepis was an Ubuntu reskin that had >>>> officially partnered with Ubuntu, had press releases from both sides to >>>> that effect, and was relying on Ubuntu's upstream source repositories >>>> for all the packages they hadn't modified. The FSF sued the one >>>> full-time guy doing Mepis for not mirroring all those unmodified source >>>> packages. I can send you links if you like.) >>> hmm if thats true, that's pretty evil. >> That's what I thought, yes: >> >> http://lwn.net/Articles/193852/ >> http://landley.net/code/toybox/licenserant.html >> http://landley.net/notes-2008.html#13-12-2008 >> > > i've read that all, but it doesn't seem unnecessarily cruel. > a) both cases are about GPL 2 / LGPL 2, not GPL 3 After almost two decades of dealing with it (EMX under OS/2, baby!) I understand the nooks and crannies of GPLv2 pretty darn well. I don't pretend to understand GPLv3 in that detail, and don't want to. It's a much bigger and more complicated license. Plus, most of what I distribute _isn't_ FSF code, and the versions I do are older versions they're less interested in defending. I'm limiting my exposure to the crazy people. > b) in the case of the mepis distribution (which is commercially > oriented) the guy obviously missed to provide proper > build scripts to let the user easily change his code. He did a bog standard debian derivative. All that stuff was extensively documented in Debian already. > i don't see > any reference to a court trial or similar, it looks > more as if the FSF just contacted the guy and told him to change his > stuff, which he obviously did. The FSF has lawyers (although Moglen got fed up with them and left to form a new organization, the SLFC). This guy was a garage operation that did not have the budget to even show up in court and plead "not guilty" with representation other than a public defender. It's the same way patent trolls shake down small companies for payments because defending against a patent lawsuit _when_you_succeed_ costs on average over $2 million per instance, and a lot of small businesses either can't afford or think it's good busienss to settle for 1/10th of that. The FSF was threatening to sue this guy, which would have bankrupted him long before a verdict. > c) the cisco case: it seems the FSF was trying to talk with cisco for > about 2 years to get them to provide source and > build scripts for every piece of GNU sw they used. Did I mention that when that happened I was coincidentally working a brief contract at cisco (a couple months, helping them set up their new open source strategy)? http://landley.net/notes-2008.html#05-12-2008 I had gotten to know the developers quite well (I was working directly with the remaining guys who had moved to california when Cisco BOUGHT Linksys in the first place), and when it went down I got their side of the story? Trust me, the FSF was talking out of its ass here. It led to me washing my hands of the SFLC: http;//landley.net/notes-2009.html#15-12-2009 > since cisco didn't manage to do that, it was actually necessary to > go to court, to prove that the GPL is not a farce > but something to care about, even for big business. Hi, I'm the guy who introduced BusyBox and the SFLC and was the plantiff in about half a dozen lawsuits in the US and even one in Europe. We very much proved that GPLv2 is enforceable in court, it had nothing to do with the FSF, and the FSF's actions put a stop to my participation in such activities. They did it because once again, they were utterly irrelevant and felt left out, so they struck out blindly to grab the spotlight. The end result was that CISCO DISSOLVED THE LINKSYS DIVISION AND GOT OUT OF LINUX DEVELOPMENT ENTIRELY. (Outsourced what they couldn't immediately kill to Red Hat, if I recall.) > if cisco had followed the instructions received by the FSF, they had > gotten away with the costs of one salary for the > open source officer. > additionally, i can still get linksys routers at the local computer > store. so the linux business of cisco was not > really destroyed... A) A large chunk of the linksys routers don't run Linux, they run some other embedded micro-OS outsourced from Taiwan that fits in 2 megs of flash. (This is why they came out with the WRT54GL with the L standing for Linux, for the people who wanted something to install OpenWRT or similar on back before 8 gazillion other companies had cloned it.) B) Development on the Linux stuff has ceased and the Linux engineers I knew no longer work for the company. Cisco still owns the Linksys name and the old products they'd already developed still exist, but it's not updated (except for security fixes, which are outsourced). >> Then in 2006 (YEARS after the kernel locked down its license), the FSF >> quoted Darth Vader from The Empire Strikes Back, "I am altering the >> bargain, pray I don't alter it any further", and the Linux kernel >> developers went "When we said we were sticking with GPLv2 we meant it", >> the FSF guys said "you'll change", the Linux developers came out with a >> statement that they wouldn't: >> >> http://lwn.net/Articles/200422/ > well i guess switching to GPLv3 could have really pissed of the majority > of corporate kernel investors (intel et al.), > so that was never a real option... If you think that Linus is particularly influenced by that, you don't know him very well. (And Samba switched to GPLv3 years ago, corporate types continue to use it anyway because it interfaces with Windows and they want to do that. Linux has not, and won't.) Rob 1317928943.0 From rob at landley.net Thu Oct 6 21:57:48 2011 From: rob at landley.net (Rob Landley) Date: Thu, 06 Oct 2011 16:57:48 -0500 Subject: [Aboriginal] Build error In-Reply-To: References: Message-ID: <4E8E245C.9050505@landley.net> On 10/06/2011 09:18 AM, prasanna balan wrote: > I tried building aboriginal 1.1.0 and it broke during uClibc++ native > compiler...The last few lines of the build are as below: You just ran ./build.sh i686? > =============================================================================================== > ln gcc i686-unknown-linux-gcc-tmp && \ > mv -f i686-unknown-linux-gcc-tmp i686-unknown-linux-gcc ); \ > fi > make[1]: Leaving directory > `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/build-gcc/gcc' > cleanup build-gcc > cleanup gcc-core > === ccwrap (i686 native-compiler) > === uClibc++ (i686 native-compiler) > Snapshot 'uClibc++'... > make -C extra/config conf > make[1]: Entering directory > `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config' > make[1]: *** ../../.config: Is a directory. Stop. > make[1]: Leaving directory > `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config' > make: *** [extra/config/conf] Error 2 Huh. That's odd. > Exiting due to errors (i686 native-compiler uClibc++) > > real 19m9.994s > user 15m44.539s > sys 1m58.504s > ================================================================================================= > Everything upto this point runs fine. I use slackware-x86 distro. > Basically there's no folder named /extra/config/conf... Actually it's looking for /home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config/../../.config And finding a directory named ".config" under "uClibc++/extra/config". Which is weird, and possibly the wrong error message. > thus make -C > breaks..but then > how did it build earlier...or is it something else.... Which version of slackware, 32 or 64 bit, and what filesystem type is mounted on /home? I'll install it in a VM here and see if I can reproduce the problem... I note that if you don't need c++ you can uncomment the "export NO_CPLUSPLUS=1" in your config file at the top of the aboriginal source and try again. That skips this whole package. But I would much rather debug this properly, which probably means reproducing it here... Rob 1317938268.0 From rob at landley.net Thu Oct 6 22:01:28 2011 From: rob at landley.net (Rob Landley) Date: Thu, 06 Oct 2011 17:01:28 -0500 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E8CDFC8.7060708@gmx.net> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> Message-ID: <4E8E2538.10004@landley.net> On 10/05/2011 05:52 PM, maillist-aboriginal at barfooze.de wrote: > let me answer the question in the subject first: > musl is a new libc for linux, which imo is exceptionally well made. > according to my own experience its smaller, faster and more correct than > uclibc. Huh, are you dalias under yet another name, or is this _another_ libc? This is different from the attempts to port bionic to the vanilla kernel, has no relation to klibc, is not related to uClibc, dietlibc, glibc, libc5, or any of the BSD libc projects? (What definitions of "correct" mean something other than "runs the software that's out there", by the way?) > here is a comparison: http://www.etalabs.net/compare_libcs.html > (it even has stuff which uclibc lacks, such as posix_spawn, which is a > really handy function) > > musl has ARM support since the last release and i'm currently porting > sabotage linux > to build on that arch, using aboriginal as my build platform. > there are a couple of issues (mostly the old binutils used by > aboriginal, which don't > go well together with musl's gcc wrapper, the lack of a debugger > and the speed and memory restrictions of qemu), however i'm making > progress... Most of those are on my todo list to fix. the memory restrictions should be easier to lift once device tree support properly goes into both kernel and qemu (bits are there now, maybe enough already, I have to poke at it). I've got a todo list item to add a -Bsymbolic-thingy flag but haven't gotten time to work on that yet. Have you tried building gdb natively under uClibc (statically linked) and then using that binary under a musl chroot? >>> also in my tests stuff was partially 50% faster than with -O3 alone. >>> so it's actually a pretty neat feature. >> Sounds like you're compiling badly written code, but you work with what >> you've got... >> > not really, i did test a couple of different selfwritten arraylist > implementations. > using the -flto -fwhole-program flags, i could see big speed and size > differences, > when all involved c-files where thrown at once onto the compiler, > as opposed to just linking object files together. *shrug* Ok. >>> i was talking about gcc *3*. >> Ah, I missed that. >> >> There are arguments for supporting older toolchain versions, and >> arguments for supporting newer toolchain versions. Mostly I just want a >> working toolchain to bootstrap a target, and then you can natively build >> a new toolchain under that in things like lfs-bootstrap.hdc. >> > i actually think a handful of patches on the kernel source would suffice > to still build a complete linux system using gcc 3. > given the immense memory requirements when compiling gcc4.5+it could > even be possible that gcc 3 is the only vital option. Except there are lots of target output types that doesn't support. >> The interesting thing that newer gcc versions give you is support for >> more targets. For example, armv7 showed up in gcc 4.3, which is the big >> incentive to support the newer one. Support for the xylinx microblaze >> would also be nice, since qemu has that now. Alpha and m68k compilers >> that don't die so often with internal compiler errors while cross >> compiling stuff would also be cool, although I the native versions of >> those compilers might be more stable. >> > indeed, the more targets, the better. however i've seen in gcc's > changelog that > in the last releases some old architectures have been removed... Did I mention I think the FSF is really really bad at software engineering? >>> the build time on my 3ghz machine is 5 minutes compared to 45 minutes >>> for gcc4.5 (without mpc/mpfr/gmp, who consume another 5 minutes alone) >>> only thing missing is the gnu99 inline stuff. apart from that it >>> compiles 99% of the code out there. >> It is indeed cool. But if I recall it couldn't do simple dead code >> elimination on arm, meaning busybox had a build break trying to link >> code out of .c files it hadn't bothered to compile because it knew they >> wouldn't be used. >> > yep, that's the tradeoff you have to make... features vs bloat :/ With FSF code, maybe. In general, you can do efficient implementations and get a good bang for the byte. (THEY can't, but see "bad at software", above.) >>> never heard about tcg. i'll read up on that one. >> There's a README in qemu's tcg subdirectory. See also >> http://127.0.0.1/qemu/2008-01-29.html#Feb_1,_2008_-_TCG >> > thanks, that looks pretty interesting. > the level of optimization done is tiny, though (no idea how much it was > improved since then). But the time it takes to compile code is also tiny. (This code generator is on par with if not faster than the one in tcc.) >>> i can load the file into vi, both using the symlink and the link target. >>> musl's readdir is just a one liner around the kernel syscall. >> Use strace to see what arguments it's passing to the syscall. >> > > yep, using strace i could hunt down the bug. > i was previously inserting printf's into musl code and recompiling > everytime due to a lacking debugger... > not really used to that kind of debugging. getting a working statically > compiled gdb for ARM is on the > top of my TODO list. Have you tried building it natively under either dev-environment.sh's /home or under the filesystem lfs-bootstrap.hdc produces? > musl had fcntl.h with values from i386, which slightly differ from ARM, so > the O_LARGEFILE of musl's open() was interpreted as O_NOFOLLOW from the > kernel. > was fixed yesterday by > http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e6d765a8b1278e9e5f507638ccdec9fe40e52364 Yeah that'll do it. > (that's also a nice thing about musl, i report the bug and 10 minutes > later it is fixed, usually) Cool. I try to fix issues the same week they're reported (clearing my backlog on weekends), but don't always succeed. (I have a day job and working on this isn't it.) Rob 1317938488.0 From maillist-aboriginal at barfooze.de Thu Oct 6 23:20:31 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Fri, 07 Oct 2011 01:20:31 +0200 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E8E2538.10004@landley.net> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> Message-ID: <4E8E37BF.3070304@barfooze.de> On 10/07/2011 12:01 AM, Rob Landley wrote: > On 10/05/2011 05:52 PM, maillist-aboriginal at barfooze.de wrote: >> let me answer the question in the subject first: >> musl is a new libc for linux, which imo is exceptionally well made. >> according to my own experience its smaller, faster and more correct than >> uclibc. > Huh, are you dalias under yet another name, no. but dalias is indeed the author of musl libc. btw, he used aboriginal to make the arm port. > or is this _another_ libc? it is another libc if compared to the ones mentioned below. not sure what you're refering to here. > This is different from the attempts to port bionic to the vanilla > kernel, has no relation to klibc, is not related to uClibc, dietlibc, > glibc, libc5, or any of the BSD libc projects? > yep, different attempt. and so far it's looking very sweet. couldn't do it better myself. completeness status is reflected in the version number which is 0.8.xx there's some C99 math stuff missing and no C++ support yet, but apart from that nearly everything compiles now (after fixing broken/idiotic build systems and gnu assumptions, of course) > (What definitions of "correct" mean something other than "runs the > software that's out there", by the way?) > one example for correctness is that musl doesnt implement a 32bit off_t api, because if you allow both you can have a 32-bit off_t program invoked by a 64-bit off_t shell... its stdin/out/err will be in 64-bit mode... >> here is a comparison: http://www.etalabs.net/compare_libcs.html >> (it even has stuff which uclibc lacks, such as posix_spawn, which is a >> really handy function) >> >> musl has ARM support since the last release and i'm currently porting >> sabotage linux >> to build on that arch, using aboriginal as my build platform. >> there are a couple of issues (mostly the old binutils used by >> aboriginal, which don't >> go well together with musl's gcc wrapper, the lack of a debugger >> and the speed and memory restrictions of qemu), however i'm making >> progress... > Most of those are on my todo list to fix. the memory restrictions > should be easier to lift once device tree support properly goes into > both kernel and qemu (bits are there now, maybe enough already, I have > to poke at it). I've got a todo list item to add a -Bsymbolic-thingy > flag but haven't gotten time to work on that yet. actually it would be sweet to have ld.gold around, but that'd require a working C++ env (at least to build it, statically preferred ;)) i was told that it is faster and takes way less ram than gnu ld. (which is not very surprising, given the quality of average gnu code) > Have you tried building gdb natively under uClibc (statically linked) > and then using that binary under a musl chroot? > >>>> also in my tests stuff was partially 50% faster than with -O3 alone. >>>> so it's actually a pretty neat feature. >>> Sounds like you're compiling badly written code, but you work with what >>> you've got... >>> >> not really, i did test a couple of different selfwritten arraylist >> implementations. >> using the -flto -fwhole-program flags, i could see big speed and size >> differences, >> when all involved c-files where thrown at once onto the compiler, >> as opposed to just linking object files together. > *shrug* Ok. > >>>> i was talking about gcc *3*. >>> Ah, I missed that. >>> >>> There are arguments for supporting older toolchain versions, and >>> arguments for supporting newer toolchain versions. Mostly I just want a >>> working toolchain to bootstrap a target, and then you can natively build >>> a new toolchain under that in things like lfs-bootstrap.hdc. >>> >> i actually think a handful of patches on the kernel source would suffice >> to still build a complete linux system using gcc 3. >> given the immense memory requirements when compiling gcc4.5+it could >> even be possible that gcc 3 is the only vital option. > Except there are lots of target output types that doesn't support. > indeed. >>> The interesting thing that newer gcc versions give you is support for >>> more targets. For example, armv7 showed up in gcc 4.3, which is the big >>> incentive to support the newer one. Support for the xylinx microblaze >>> would also be nice, since qemu has that now. Alpha and m68k compilers >>> that don't die so often with internal compiler errors while cross >>> compiling stuff would also be cool, although I the native versions of >>> those compilers might be more stable. >>> >> indeed, the more targets, the better. however i've seen in gcc's >> changelog that >> in the last releases some old architectures have been removed... > Did I mention I think the FSF is really really bad at software engineering? > full ack. what sucks most tho are the build systems used by gnu. i guess to fully grok gcc's build system you have to become Phd at the gnu university. >>>> the build time on my 3ghz machine is 5 minutes compared to 45 minutes >>>> for gcc4.5 (without mpc/mpfr/gmp, who consume another 5 minutes alone) >>>> only thing missing is the gnu99 inline stuff. apart from that it >>>> compiles 99% of the code out there. >>> It is indeed cool. But if I recall it couldn't do simple dead code >>> elimination on arm, meaning busybox had a build break trying to link >>> code out of .c files it hadn't bothered to compile because it knew they >>> wouldn't be used. >>> >> yep, that's the tradeoff you have to make... features vs bloat :/ > With FSF code, maybe. In general, you can do efficient implementations > and get a good bang for the byte. (THEY can't, but see "bad at > software", above.) > >>>> never heard about tcg. i'll read up on that one. >>> There's a README in qemu's tcg subdirectory. See also >>> http://127.0.0.1/qemu/2008-01-29.html#Feb_1,_2008_-_TCG >>> >> thanks, that looks pretty interesting. >> the level of optimization done is tiny, though (no idea how much it was >> improved since then). > But the time it takes to compile code is also tiny. (This code > generator is on par with if not faster than the one in tcc.) > sweet. i imagine a compiler which could crosscompile to any wished target by just adding a flag. >>>> i can load the file into vi, both using the symlink and the link target. >>>> musl's readdir is just a one liner around the kernel syscall. >>> Use strace to see what arguments it's passing to the syscall. >>> >> yep, using strace i could hunt down the bug. >> i was previously inserting printf's into musl code and recompiling >> everytime due to a lacking debugger... >> not really used to that kind of debugging. getting a working statically >> compiled gdb for ARM is on the >> top of my TODO list. > Have you tried building it natively under either dev-environment.sh's > /home or under the filesystem lfs-bootstrap.hdc produces? > not yet, will try later today. in fact i ported gdb to build on musl on intel targets and it was a fscking patch orgy. maybe that experience kept me from trying to build it with uclibc yet. the number of glibc-specific assumptions gdb makes is huge, not to talk about *gnulib*, which is broken by design, and of course is "built-in" into gdb. >> musl had fcntl.h with values from i386, which slightly differ from ARM, so >> the O_LARGEFILE of musl's open() was interpreted as O_NOFOLLOW from the >> kernel. >> was fixed yesterday by >> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e6d765a8b1278e9e5f507638ccdec9fe40e52364 > Yeah that'll do it. > >> (that's also a nice thing about musl, i report the bug and 10 minutes >> later it is fixed, usually) > Cool. I try to fix issues the same week they're reported (clearing my > backlog on weekends), but don't always succeed. (I have a day job and > working on this isn't it.) (heh, you still didn't fix the busybox "patch program" bug with path levels i reported on the busybox mailling list. thats why sabotage uses gnu patch now ;)) > Rob > 1317943231.0 From maillist-aboriginal at barfooze.de Fri Oct 7 03:32:56 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Fri, 07 Oct 2011 05:32:56 +0200 Subject: [Aboriginal] lsi_scsi: error Message-ID: <4E8E72E8.30409@barfooze.de> on the previous version of aboriginal (1.01 ?) armv6l (didn't test 1.1 yet), i keep getting the following error/warning, when compiling big stuff, or even while extracting gcc 4.5.3 core's tarball (xf only). lsi_scsi: error: ORDERED queue not implemented despite the "error", it seems everything works, however it's kinda annoying. is that a bug in aboriginal or in my local qemu install ? "QEMU emulator version 0.13.91, Copyright (c) 2003-2008 Fabrice Bellard" 1317958376.0 From rob at landley.net Fri Oct 7 03:47:53 2011 From: rob at landley.net (Rob Landley) Date: Thu, 06 Oct 2011 22:47:53 -0500 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E8E37BF.3070304@barfooze.de> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> Message-ID: <4E8E7669.7040502@landley.net> On 10/06/2011 06:20 PM, John Spencer wrote: > On 10/07/2011 12:01 AM, Rob Landley wrote: >> On 10/05/2011 05:52 PM, maillist-aboriginal at barfooze.de wrote: >>> let me answer the question in the subject first: >>> musl is a new libc for linux, which imo is exceptionally well made. >>> according to my own experience its smaller, faster and more correct than >>> uclibc. >> Huh, are you dalias under yet another name, > > no. but dalias is indeed the author of musl libc. > btw, he used aboriginal to make the arm port. Ok, I've talked to him on and off for years in #edev and #uclibc and the busybox mailing list and such, I'm aware of his effort. Sounds like fun, I'm just trying to keep track. :) >> or is this _another_ libc? > > it is another libc if compared to the ones mentioned below. > not sure what you're refering to here. It's nice to have a good small simple libc. It would be _really_ nice to document the steps to adding a new target. (In aboriginal, all the information about a specific target is in the sources/targets files, one per target. At one point many moons ago i had documentation about adding a new target. um... http://landley.net/aboriginal/documentation.html#new_target I think. Wow that's out of date...) >> This is different from the attempts to port bionic to the vanilla >> kernel, has no relation to klibc, is not related to uClibc, dietlibc, >> glibc, libc5, or any of the BSD libc projects? >> > yep, different attempt. and so far it's looking very sweet. couldn't do > it better myself. > completeness status is reflected in the version number which is 0.8.xx > there's some C99 math stuff missing and no C++ support yet, but apart > from that nearly everything compiles now Why should libc care about c++ again? C++ is not C, any more than Objective C is. Java borrowed a lot of C's syntax, and isn't C either. > (after fixing broken/idiotic build systems and gnu assumptions, of course) >> (What definitions of "correct" mean something other than "runs the >> software that's out there", by the way?) >> > one example for correctness is that musl doesnt implement a 32bit off_t > api, because if you allow both you can have > a 32-bit off_t program invoked by a 64-bit off_t shell... > its stdin/out/err will be in 64-bit mode... Removing obsolete broken crap: yay! You'd think uClibc would be the project for this, but that was before: http://lists.busybox.net/pipermail/uclibc/2007-September/039215.html And although I spent YEARS nudging it back together (and out from under buildroot's shadow), it's nowhere near recovered yet and I've got too much else to do... >>> here is a comparison: http://www.etalabs.net/compare_libcs.html >>> (it even has stuff which uclibc lacks, such as posix_spawn, which is a >>> really handy function) >>> >>> musl has ARM support since the last release and i'm currently porting >>> sabotage linux >>> to build on that arch, using aboriginal as my build platform. >>> there are a couple of issues (mostly the old binutils used by >>> aboriginal, which don't >>> go well together with musl's gcc wrapper, the lack of a debugger >>> and the speed and memory restrictions of qemu), however i'm making >>> progress... >> Most of those are on my todo list to fix. the memory restrictions >> should be easier to lift once device tree support properly goes into >> both kernel and qemu (bits are there now, maybe enough already, I have >> to poke at it). I've got a todo list item to add a -Bsymbolic-thingy >> flag but haven't gotten time to work on that yet. > actually it would be sweet to have ld.gold around, but that'd require a > working C++ env > (at least to build it, statically preferred ;)) In theory, the system images I built and posted have working c++ toolchains in them, based on uClibc+=. Haven't stressed it much, but it builds hello world with the funky "we redefined the bit shift operators to perform I/O" stuff. (It died building cmake, I have to go back and work out why...) > i was told that it is faster and takes way less ram than gnu ld. > (which is not very surprising, given the quality of average gnu code) The tinycc linker is also buckets faster and less memory intensive than gnu ld. Too bad the maintainer of that project is a windows developer, if it would just DIE I'd restart my fork but I refuse to fight zombies without a cricket bat. >>> indeed, the more targets, the better. however i've seen in gcc's >>> changelog that >>> in the last releases some old architectures have been removed... >> Did I mention I think the FSF is really really bad at software >> engineering? >> > full ack. what sucks most tho are the build systems used by gnu. > i guess to fully grok gcc's build system you have to become Phd at the > gnu university. http://landley.net/notes-2010.html#11-11-2010 http://landley.net/notes-2010.html#15-10-2010 http://landley.net/notes-2010.html#26-08-2010 http://landley.net/notes-2010.html#20-08-2010 And so on, and so forth. Trust me: they don't understand it either. They just keep adding another special case for each new test case. Literally. That is the design of autoconf. >>> thanks, that looks pretty interesting. >>> the level of optimization done is tiny, though (no idea how much it was >>> improved since then). >> But the time it takes to compile code is also tiny. (This code >> generator is on par with if not faster than the one in tcc.) >> > sweet. i imagine a compiler which could crosscompile to any wished > target by just adding a flag. Basically, yeah. :) You have to add said flag to the preprocessor as well, it sets a bunch of symbols telling you about your current target. Go: gcc -E -dM - < /dev/null | less Now do that for each of the cross compilers and diff the result. :) >> Have you tried building it natively under either dev-environment.sh's >> /home or under the filesystem lfs-bootstrap.hdc produces? >> > not yet, will try later today. in fact i ported gdb to build on musl on > intel targets and it was > a fscking patch orgy. maybe that experience kept me from trying to build > it with uclibc yet. I've learned not to try to fix FSF code, I've learned to lie to it and/or bypass large chunks of it instead. You've learned never to install Libtool on Linux, right? http://landley.net/notes-2006.html#10-10-2006 Libtool exists to make non-ELF systems work like ELF systems. When used on a system that _is_ using ELF linking, it should be a NOP. Having nothing to do and still screwing it up is a registered trademark of the free software foundation. > the number of glibc-specific assumptions gdb makes is huge, not to talk > about *gnulib*, > which is broken by design, and of course is "built-in" into gdb. >>> musl had fcntl.h with values from i386, which slightly differ from >>> ARM, so >>> the O_LARGEFILE of musl's open() was interpreted as O_NOFOLLOW from the >>> kernel. >>> was fixed yesterday by >>> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e6d765a8b1278e9e5f507638ccdec9fe40e52364 >>> >> Yeah that'll do it. >> >>> (that's also a nice thing about musl, i report the bug and 10 minutes >>> later it is fixed, usually) >> Cool. I try to fix issues the same week they're reported (clearing my >> backlog on weekends), but don't always succeed. (I have a day job and >> working on this isn't it.) > (heh, you still didn't fix the busybox "patch program" bug with path > levels i reported on the busybox mailling list. > thats why sabotage uses gnu patch now ;)) Um, send me a link again? Rob 1317959273.0 From prazzb at gmail.com Fri Oct 7 04:49:27 2011 From: prazzb at gmail.com (prasanna balan) Date: Fri, 7 Oct 2011 10:19:27 +0530 Subject: [Aboriginal] Build error In-Reply-To: <4E8E245C.9050505@landley.net> References: <4E8E245C.9050505@landley.net> Message-ID: On 7 Oct 2011 03:27, "Rob Landley" wrote: > > On 10/06/2011 09:18 AM, prasanna balan wrote: > > I tried building aboriginal 1.1.0 and it broke during uClibc++ native > > compiler...The last few lines of the build are as below: > > You just ran ./build.sh i686? > Forgot to mention. It was. /build.sh i686 > > =============================================================================================== > > ln gcc i686-unknown-linux-gcc-tmp && \ > > mv -f i686-unknown-linux-gcc-tmp i686-unknown-linux-gcc ); \ > > fi > > make[1]: Leaving directory > > `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/build-gcc/gcc' > > cleanup build-gcc > > cleanup gcc-core > > === ccwrap (i686 native-compiler) > > === uClibc++ (i686 native-compiler) > > Snapshot 'uClibc++'... > > make -C extra/config conf > > make[1]: Entering directory > > `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config' > > make[1]: *** ../../.config: Is a directory. Stop. > > make[1]: Leaving directory > > `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config' > > make: *** [extra/config/conf] Error 2 > > Huh. That's odd. > > > Exiting due to errors (i686 native-compiler uClibc++) > > > > real 19m9.994s > > user 15m44.539s > > sys 1m58.504s > > ================================================================================================= > > Everything upto this point runs fine. I use slackware-x86 distro. > > Basically there's no folder named /extra/config/conf... > > Actually it's looking for > /home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config/../../.config > > And finding a directory named ".config" under "uClibc++/extra/config". > Which is weird, and possibly the wrong error message. > > > thus make -C > > breaks..but then > > how did it build earlier...or is it something else.... > > Which version of slackware, 32 or 64 bit, and what filesystem type is > mounted on /home? I'll install it in a VM here and see if I can > reproduce the problem... > > I note that if you don't need c++ you can uncomment the "export > NO_CPLUSPLUS=1" in your config file at the top of the aboriginal source > and try again. That skips this whole package. But I would much rather > debug this properly, which probably means reproducing it here... I tried with NO_CPLUSPLUS =1 and it built without break means some issue with uclibc++ exists. I use 32 bit slackware current with ext4 fs on /home > > Rob prazzb -------------- next part -------------- An HTML attachment was scrubbed... URL: From maillist-aboriginal at barfooze.de Sat Oct 8 05:19:56 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Sat, 08 Oct 2011 07:19:56 +0200 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E8E7669.7040502@landley.net> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> <4E8E7669.7040502@landley.net> Message-ID: <4E8FDD7C.9000607@barfooze.de> On 10/07/2011 05:47 AM, Rob Landley wrote: > On 10/06/2011 06:20 PM, John Spencer wrote: >> On 10/07/2011 12:01 AM, Rob Landley wrote: >>> On 10/05/2011 05:52 PM, maillist-aboriginal at barfooze.de wrote: >>>> let me answer the question in the subject first: >>>> musl is a new libc for linux, which imo is exceptionally well made. >>>> according to my own experience its smaller, faster and more correct than >>>> uclibc. >>> Huh, are you dalias under yet another name, >> no. but dalias is indeed the author of musl libc. >> btw, he used aboriginal to make the arm port. > Ok, I've talked to him on and off for years in #edev and #uclibc and the > busybox mailing list and such, I'm aware of his effort. Sounds like > fun, I'm just trying to keep track. :) > ah, i see. >>> or is this _another_ libc? >> it is another libc if compared to the ones mentioned below. >> not sure what you're refering to here. > It's nice to have a good small simple libc. It would be _really_ nice > to document the steps to adding a new target. here's a writeup from the amd64 port: http://brightrain.aerifal.cx/~niklata/PORTING this commit here documents about everything needed for the arm port http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=d960d4f2cbf18ff3476c7ac03698ec253885dd8e and these two here add dynamic linking to musl arm http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=12ace5bf76040e928df1abd57e9b5134ca4647c6 http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=fcaf7065698bce12a444803587421ae88446f6c0 see how little code was needed... > (In aboriginal, all the information about a specific target is in the > sources/targets files, one per target. At one point many moons ago i > had documentation about adding a new target. um... > http://landley.net/aboriginal/documentation.html#new_target I think. > Wow that's out of date...) > >>> This is different from the attempts to port bionic to the vanilla >>> kernel, has no relation to klibc, is not related to uClibc, dietlibc, >>> glibc, libc5, or any of the BSD libc projects? >>> >> yep, different attempt. and so far it's looking very sweet. couldn't do >> it better myself. >> completeness status is reflected in the version number which is 0.8.xx >> there's some C99 math stuff missing and no C++ support yet, but apart >> from that nearly everything compiles now > Why should libc care about c++ again? C++ is not C, any more than > Objective C is. Java borrowed a lot of C's syntax, and isn't C either. > indeed, i actually would prefer a system without any C++ crap. however there are many useful apps written in it (like gold), and to get wide acceptance musl has to get some way to build C++ stuff. it's unlikely that the GCC guys will do it... >> (after fixing broken/idiotic build systems and gnu assumptions, of course) >>> (What definitions of "correct" mean something other than "runs the >>> software that's out there", by the way?) >>> >> one example for correctness is that musl doesnt implement a 32bit off_t >> api, because if you allow both you can have >> a 32-bit off_t program invoked by a 64-bit off_t shell... >> its stdin/out/err will be in 64-bit mode... > Removing obsolete broken crap: yay! > > You'd think uClibc would be the project for this, but that was before: > > http://lists.busybox.net/pipermail/uclibc/2007-September/039215.html > > And although I spent YEARS nudging it back together (and out from under > buildroot's shadow), it's nowhere near recovered yet and I've got too > much else to do... > >>>> here is a comparison: http://www.etalabs.net/compare_libcs.html >>>> (it even has stuff which uclibc lacks, such as posix_spawn, which is a >>>> really handy function) >>>> >>>> musl has ARM support since the last release and i'm currently porting >>>> sabotage linux >>>> to build on that arch, using aboriginal as my build platform. >>>> there are a couple of issues (mostly the old binutils used by >>>> aboriginal, which don't >>>> go well together with musl's gcc wrapper, the lack of a debugger >>>> and the speed and memory restrictions of qemu), however i'm making >>>> progress... >>> Most of those are on my todo list to fix. the memory restrictions >>> should be easier to lift once device tree support properly goes into >>> both kernel and qemu (bits are there now, maybe enough already, I have >>> to poke at it). I've got a todo list item to add a -Bsymbolic-thingy >>> flag but haven't gotten time to work on that yet. >> actually it would be sweet to have ld.gold around, but that'd require a >> working C++ env >> (at least to build it, statically preferred ;)) > In theory, the system images I built and posted have working c++ > toolchains in them, based on uClibc+=. Haven't stressed it much, but it > builds hello world with the funky "we redefined the bit shift operators > to perform I/O" stuff. > > (It died building cmake, I have to go back and work out why...) > not really in the mood to fight with C++ code currently. btw, i could compile gcc 4.5.3 by passing -Wl,--no-keep-memory to the linker. i also added a patch which disables target-libiberty and target-libz. with disable-bootstrap the compiler built in around 15 minutes using distcc o.0 so it actually looks as if --no-keep-memory actually is *faster* despite being described as "slow but less memory hungry" >> i was told that it is faster and takes way less ram than gnu ld. >> (which is not very surprising, given the quality of average gnu code) > The tinycc linker is also buckets faster and less memory intensive than > gnu ld. how about this one ? http://code.google.com/p/ucpp/ > Too bad the maintainer of that project is a windows developer, > if it would just DIE I'd restart my fork but I refuse to fight zombies > without a cricket bat. hmm iirc the mob branch is the only active. it's not even that bad, i checked it out lately and it built stuff which tcc 0.9.25 refused to build. >>>> indeed, the more targets, the better. however i've seen in gcc's >>>> changelog that >>>> in the last releases some old architectures have been removed... >>> Did I mention I think the FSF is really really bad at software >>> engineering? >>> >> full ack. what sucks most tho are the build systems used by gnu. >> i guess to fully grok gcc's build system you have to become Phd at the >> gnu university. > http://landley.net/notes-2010.html#11-11-2010 > http://landley.net/notes-2010.html#15-10-2010 > http://landley.net/notes-2010.html#26-08-2010 > http://landley.net/notes-2010.html#20-08-2010 > > And so on, and so forth. Trust me: they don't understand it either. > They just keep adding another special case for each new test case. > > Literally. That is the design of autoconf. > interesting lecture. i actually think it would make sense to writeup a "serious" blog post [web 2.0 like with comments and such] about autoconf, with some examples like these here and link it on reddit. compiling stuff could be so much fun if autoconf'd build systems wouldn't always fuck everything up. actually it is so broken that it defeats the purpose of the FSF, in that it makes it too hard to change and recompile your free software, making it unfree that way. >>>> thanks, that looks pretty interesting. >>>> the level of optimization done is tiny, though (no idea how much it was >>>> improved since then). >>> But the time it takes to compile code is also tiny. (This code >>> generator is on par with if not faster than the one in tcc.) >>> >> sweet. i imagine a compiler which could crosscompile to any wished >> target by just adding a flag. > Basically, yeah. :) > > You have to add said flag to the preprocessor as well, it sets a bunch > of symbols telling you about your current target. Go: > > gcc -E -dM -< /dev/null | less > > Now do that for each of the cross compilers and diff the result. :) ... thats quite a list. >>> Have you tried building it natively under either dev-environment.sh's >>> /home or under the filesystem lfs-bootstrap.hdc produces? >>> >> not yet, will try later today. in fact i ported gdb to build on musl on >> intel targets and it was >> a fscking patch orgy. maybe that experience kept me from trying to build >> it with uclibc yet. > I've learned not to try to fix FSF code, I've learned to lie to it > and/or bypass large chunks of it instead. > > You've learned never to install Libtool on Linux, right? most stuff actually seems to come with its own libtool. however i just found out that you have to delete *.la and magically stuff builds, that failed earlier. > http://landley.net/notes-2006.html#10-10-2006 > > Libtool exists to make non-ELF systems work like ELF systems. When used > on a system that _is_ using ELF linking, it should be a NOP. > > Having nothing to do and still screwing it up is a registered trademark > of the free software foundation. > >> the number of glibc-specific assumptions gdb makes is huge, not to talk >> about *gnulib*, >> which is broken by design, and of course is "built-in" into gdb. >>>> musl had fcntl.h with values from i386, which slightly differ from >>>> ARM, so >>>> the O_LARGEFILE of musl's open() was interpreted as O_NOFOLLOW from the >>>> kernel. >>>> was fixed yesterday by >>>> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=e6d765a8b1278e9e5f507638ccdec9fe40e52364 >>>> >>> Yeah that'll do it. >>> >>>> (that's also a nice thing about musl, i report the bug and 10 minutes >>>> later it is fixed, usually) >>> Cool. I try to fix issues the same week they're reported (clearing my >>> backlog on weekends), but don't always succeed. (I have a day job and >>> working on this isn't it.) >> (heh, you still didn't fix the busybox "patch program" bug with path >> levels i reported on the busybox mailling list. >> thats why sabotage uses gnu patch now ;)) > Um, send me a link again? http://lists.busybox.net/pipermail/busybox/2011-July/076293.html > Rob > > 1318051196.0 From maillist-aboriginal at barfooze.de Sat Oct 8 05:55:56 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Sat, 08 Oct 2011 07:55:56 +0200 Subject: [Aboriginal] aboriginal In-Reply-To: <4E8DFFEF.2000404@landley.net> References: <4E7E0A79.6060609@gmx.net> <4E7EB7A5.2040907@landley.net> <4E7F4B15.3030803@gmx.net> <4E81C278.3020707@landley.net> <4E89019F.6050808@gmx.net> <4E8B66BB.6060106@landley.net> <4E8CD86B.9010503@barfooze.de> <4E8DFFEF.2000404@landley.net> Message-ID: <4E8FE5EC.6010905@barfooze.de> On 10/06/2011 09:22 PM, Rob Landley wrote: > On 10/05/2011 05:21 PM, John Spencer wrote: >> On 10/04/2011 10:04 PM, Rob Landley wrote: >>> On 10/02/2011 07:28 PM, maillist-aboriginal at barfooze.de wrote: >>>> On 09/27/2011 02:32 PM, Rob Landley wrote: >>>>> On 09/25/2011 10:39 AM, maillist-aboriginal at barfooze.de wrote: >>>>>> On 09/25/2011 07:09 AM, Rob Landley wrote: >>>>>>> On 09/24/2011 11:51 AM, maillist-aboriginal at barfooze.de wrote: >>>>>>>> hi, was playing around with aboriginal lately. >>>>>>>> since i haven't seen you on #uclibc lately, i thought i'd just >>>>>>>> write a >>>>>>>> mail... >>>>>>> I'm on the road at the moment, with limited internet access. I get >>>>>>> home >>>>>>> the 27th. >>>>>>> >>>>>>>> i was wondering why gcc 4.2.1 has been chosen (i know that 4.2.4 is >>>>>>>> the >>>>>>>> last one that builds without dependency libraries) >>>>>>> 4.2.1 was the last GPLv2 release. I've built newer ones, but don't >>>>>>> distribute them. I'll probably check in a script to do so at some >>>>>>> point, and add a config option for it. >>>>>>> >>>>>> hmm... what's the difficulty with GPL v3 if i may ask ? >>>>> 1) It's not the license the Linux kernel is under, and is incompatible >>>>> with the Linux kernel. >>>> hmm, didnt know that. is that only for binary distributions ? >>> Pretty much all open source licenses only put conditions on binary >>> distribution. Restricting source distribution means "you aren't >>> remotely open source". >> hmm. that means you have to add a note to the linux distribution that a >> DVD containing the sources >> can be ordered at address xy. or you just put up a download which >> contains all the sources. >> that's slightly uncomfortable since it is more work, but not really a >> big problem, since you basically just have >> to publish your already existing build environment plus some tarballs. > Oh I'm mirroring all the gplv2 stuff (and possibly some bsd stuff) at > http://landley.net/aboriginal/mirror > > I've spoken to Eben Moglen (co-author of both GPLv2 and GPLv3) about > this when I visited the SFLC's office in New York (which was handling > the busybox license enforcement lawsuits), and he _almost_ convinced me > that GPLv3 wasn't worth opposing. indeed, seems to much effort, or leaves you behind with outdated sw... > But what he couldn't convince me was that it was actually required. The > FSF did it as a giant ego trip, they trod all over the Linux community, > and I am _NOT_ a GNU developer. I'm a Linux developer. The > GNU/Linux/Dammit crusade is an attempt to write history; Linux was a > reaction to Andrew Tanenbaum's Minix (and 0.0.1 was written under it), > and has no more relationship to the gnu project than FreeBSD, Solaris, > AIX, or MacOS X do. > > Computer history is a hobby of mine, and I wrote up some of the REAL > history on this topic (as I understand it) last year: > > http://landley.net/notes-2010.html#17-07-2010 > http://landley.net/notes-2010.html#19-07-2010 interesting read. afaik unix systems were relatively uncommon here in europe and only got popular with linux. so you don't really learn about that kind of history. > Linus used the FSF as a tools vendor in _exactly_ the same way the Sun > developers did, but he didn't try to claim GNU/Solaris. (Even when Ian > Murdoch got hired to do project Indiana, which was opensolaris with > mostly FSF packages for the root filesystem!) > > That said, the third parties like Code Sourcery who actually write new > code push that code upstream under the project's current license, and > since the FSF successfully recaptured EGCS stuff like armv7 and > microblaze support is either in external forks or only in newer versions > of gcc/binutils after the gplv3 switch. And pcc and llvm/clang have a > long way to go to build a workable Linux system even under x86... > oh, i actually expected clang to be mature enough to build the kernel. >>>>> blog/2009/12/15/23/2) The FSF is crazy and I don't trust them to enforce anything after >>>>> they destroyed Linksys and chased Cisco out of the Linux business. >>>>> (Cisco outsources all Linux work now so as not to get any FSF >>>>> copyrights >>>>> on them.) >>>>> Specifically, after what the FSF did to the Mepis distribution I know >>>>> they go after individuals. (Mepis was an Ubuntu reskin that had >>>>> officially partnered with Ubuntu, had press releases from both sides to >>>>> that effect, and was relying on Ubuntu's upstream source repositories >>>>> for all the packages they hadn't modified. The FSF sued the one >>>>> full-time guy doing Mepis for not mirroring all those unmodified source >>>>> packages. I can send you links if you like.) >>>> hmm if thats true, that's pretty evil. >>> That's what I thought, yes: >>> >>> http://lwn.net/Articles/193852/ >>> http://landley.net/code/toybox/licenserant.html >>> http://landley.net/notes-2008.html#13-12-2008 >>> >> i've read that all, but it doesn't seem unnecessarily cruel. >> a) both cases are about GPL 2 / LGPL 2, not GPL 3 > After almost two decades of dealing with it (EMX under OS/2, baby!) I > understand the nooks and crannies of GPLv2 pretty darn well. I don't > pretend to understand GPLv3 in that detail, and don't want to. It's a > much bigger and more complicated license. > > Plus, most of what I distribute _isn't_ FSF code, and the versions I do > are older versions they're less interested in defending. I'm limiting > my exposure to the crazy people. > >> b) in the case of the mepis distribution (which is commercially >> oriented) the guy obviously missed to provide proper >> build scripts to let the user easily change his code. > He did a bog standard debian derivative. All that stuff was extensively > documented in Debian already. > *shrug* >> i don't see >> any reference to a court trial or similar, it looks >> more as if the FSF just contacted the guy and told him to change his >> stuff, which he obviously did. > The FSF has lawyers (although Moglen got fed up with them and left to > form a new organization, the SLFC). This guy was a garage operation > that did not have the budget to even show up in court and plead "not > guilty" with representation other than a public defender. > > It's the same way patent trolls shake down small companies for payments > because defending against a patent lawsuit _when_you_succeed_ costs on > average over $2 million per instance, and a lot of small businesses > either can't afford or think it's good busienss to settle for 1/10th of > that. > > The FSF was threatening to sue this guy, which would have bankrupted him > long before a verdict. > well, maybe, but they didn't sue him in the end. >> c) the cisco case: it seems the FSF was trying to talk with cisco for >> about 2 years to get them to provide source and >> build scripts for every piece of GNU sw they used. > Did I mention that when that happened I was coincidentally working a > brief contract at cisco (a couple months, helping them set up their new > open source strategy)? > > http://landley.net/notes-2008.html#05-12-2008 > > I had gotten to know the developers quite well (I was working directly > with the remaining guys who had moved to california when Cisco BOUGHT > Linksys in the first place), and when it went down I got their side of > the story? > > Trust me, the FSF was talking out of its ass here. It led to me washing > my hands of the SFLC: > > http;//landley.net/notes-2009.html#15-12-2009 > interesting... >> since cisco didn't manage to do that, it was actually necessary to >> go to court, to prove that the GPL is not a farce >> but something to care about, even for big business. > Hi, I'm the guy who introduced BusyBox and the SFLC and was the plantiff > in about half a dozen lawsuits in the US and even one in Europe. We > very much proved that GPLv2 is enforceable in court, it had nothing to > do with the FSF, and the FSF's actions put a stop to my participation in > such activities. > > They did it because once again, they were utterly irrelevant and felt > left out, so they struck out blindly to grab the spotlight. The end > result was that CISCO DISSOLVED THE LINKSYS DIVISION AND GOT OUT OF > LINUX DEVELOPMENT ENTIRELY. (Outsourced what they couldn't immediately > kill to Red Hat, if I recall.) > ok. thats somewhat unfortunate, if it really was only about the realtek toolchain. >> if cisco had followed the instructions received by the FSF, they had >> gotten away with the costs of one salary for the >> open source officer. >> additionally, i can still get linksys routers at the local computer >> store. so the linux business of cisco was not >> really destroyed... > A) A large chunk of the linksys routers don't run Linux, they run some > other embedded micro-OS outsourced from Taiwan that fits in 2 megs of > flash. (This is why they came out with the WRT54GL with the L standing > for Linux, for the people who wanted something to install OpenWRT or > similar on back before 8 gazillion other companies had cloned it.) > > B) Development on the Linux stuff has ceased and the Linux engineers I > knew no longer work for the company. Cisco still owns the Linksys name > and the old products they'd already developed still exist, but it's not > updated (except for security fixes, which are outsourced). > ok. >>> Then in 2006 (YEARS after the kernel locked down its license), the FSF >>> quoted Darth Vader from The Empire Strikes Back, "I am altering the >>> bargain, pray I don't alter it any further", and the Linux kernel >>> developers went "When we said we were sticking with GPLv2 we meant it", >>> the FSF guys said "you'll change", the Linux developers came out with a >>> statement that they wouldn't: >>> >>> http://lwn.net/Articles/200422/ >> well i guess switching to GPLv3 could have really pissed of the majority >> of corporate kernel investors (intel et al.), >> so that was never a real option... > If you think that Linus is particularly influenced by that, you don't > know him very well. (And Samba switched to GPLv3 years ago, corporate > types continue to use it anyway because it interfaces with Windows and > they want to do that. Linux has not, and won't.) > > Rob > 1318053356.0 From rob at landley.net Sat Oct 8 16:09:55 2011 From: rob at landley.net (Rob Landley) Date: Sat, 08 Oct 2011 11:09:55 -0500 Subject: [Aboriginal] lsi_scsi: error In-Reply-To: <4E8E72E8.30409@barfooze.de> References: <4E8E72E8.30409@barfooze.de> Message-ID: <4E9075D3.4060704@landley.net> On 10/06/2011 10:32 PM, John Spencer wrote: > on the previous version of aboriginal (1.01 ?) armv6l (didn't test 1.1 > yet), > > i keep getting the following error/warning, when compiling big stuff, or > even while extracting gcc 4.5.3 core's tarball (xf only). > lsi_scsi: error: ORDERED queue not implemented Huh. I don't remember that. It sounds like a kernel issue, some kind of mismatch between the scsi driver and either the block elevator or something, but I haven't seen it... Neither did "find . -type f | xargs grep lsi_scsi" in the current linux kernel git repo. > despite the "error", it seems everything works, however it's kinda > annoying. > is that a bug in aboriginal or in my local qemu install ? Ah, there you go. Doing the find in the qemu source pulls up file hw/lsi53c895a.c containing: #define BADF(fmt, ...) \ do { fprintf(stderr, "lsi_scsi: error: " fmt , ## __VA_ARGS__);} while (0) #endif ... case 0x22: /* ORDERED queue */ BADF("ORDERED queue not implemented\n"); s->select_tag |= lsi_get_msgbyte(s) | LSI_TAG_VALID; break; The messages come from qemu. Might want to poke their mailing list about it. Since it's going to stderr, you could try running qemu with 2>/dev/null (since everything written to the linux console goes to the emulator's stdout, and thus anything qemu writes to stderr can't have come from Linux. Even if Linux internally wrote it to stderr. :) > "QEMU emulator version 0.13.91, Copyright (c) 2003-2008 Fabrice Bellard" I note that 0.15.0 is out. Doesn't look like it fixes this bug, though. Rob 1318090195.0 From rob at landley.net Sat Oct 8 17:27:38 2011 From: rob at landley.net (Rob Landley) Date: Sat, 08 Oct 2011 12:27:38 -0500 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E8FDD7C.9000607@barfooze.de> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> <4E8E7669.7040502@landley.net> <4E8FDD7C.9000607@barfooze.de> Message-ID: <4E90880A.8040104@landley.net> On 10/08/2011 12:19 AM, John Spencer wrote: > here's a writeup from the amd64 port: > http://brightrain.aerifal.cx/~niklata/PORTING > > this commit here documents about everything needed for the arm port > http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=d960d4f2cbf18ff3476c7ac03698ec253885dd8e > > > and these two here add dynamic linking to musl arm > http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=12ace5bf76040e928df1abd57e9b5134ca4647c6 > > http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=fcaf7065698bce12a444803587421ae88446f6c0 > > > see how little code was needed... Cool. I note that uClibc currently has no s390 support, but these days QEMU _does_. This means I can't support all the QEMU targets using uClibc unless their development community gets fundamentally unstuck. If musl supported that target and uClibc didn't, I'd logically want to see about getting musl support into aboriginal itself. (This would mean at minimum building current busybox against it, plus an older GPLv2 release of a gnu toolchain (gcc 4.2.1, binutils-1.17, and make 3.81 were the last GPLv2 releases, and bash 2.05b is "good enough" about about 1/3 the size of modern bash.) The rest of the packages used during the aboriginal linux build are distcc, e2fsprogs, genext2fs, and squashfs (which requires zlib). (And of course current linux but it doesn't depend on libc.) >> (In aboriginal, all the information about a specific target is in the >> sources/targets files, one per target. At one point many moons ago i >> had documentation about adding a new target. um... >> http://landley.net/aboriginal/documentation.html#new_target I think. >> Wow that's out of date...) I need at least a month to do nothing but documentation, but I know from experience it wouldn't be enough. >>>> This is different from the attempts to port bionic to the vanilla >>>> kernel, has no relation to klibc, is not related to uClibc, dietlibc, >>>> glibc, libc5, or any of the BSD libc projects? >>>> >>> yep, different attempt. and so far it's looking very sweet. couldn't do >>> it better myself. >>> completeness status is reflected in the version number which is 0.8.xx >>> there's some C99 math stuff missing and no C++ support yet, but apart >>> from that nearly everything compiles now >> Why should libc care about c++ again? C++ is not C, any more than >> Objective C is. Java borrowed a lot of C's syntax, and isn't C either. >> > > indeed, i actually would prefer a system without any C++ crap. NO_CPLUSPLUS=1 does it for aboriginal, but people keep writing stuff in it... > however there are many useful apps written in it (like gold), and to get > wide acceptance musl has to get some way to build C++ stuff. it's > unlikely that the GCC guys will do it... You're aware of uClibc++, right? (My project builds it and all. :) It's a bit stalled right now, but I have Garret's phone number around here somewhere... What's needed _in_ the libc? Stack unwinding cruft? >> In theory, the system images I built and posted have working c++ >> toolchains in them, based on uClibc+=. Haven't stressed it much, but it >> builds hello world with the funky "we redefined the bit shift operators >> to perform I/O" stuff. >> >> (It died building cmake, I have to go back and work out why...) >> > > not really in the mood to fight with C++ code currently. Neither am I. That's why it's been on my todo list for over a year. > btw, i could compile gcc 4.5.3 by passing -Wl,--no-keep-memory to the > linker. > i also added a patch which disables target-libiberty and target-libz. > with disable-bootstrap the compiler built in around 15 minutes using > distcc o.0 > so it actually looks as if --no-keep-memory actually is *faster* despite > being described as "slow but less memory hungry" The FSF remains crazy, although sometimes performance stuff is non-obvious: http://www.funtoo.org/wiki/Funtoo_Filesystem_Guide,_Part_5#data.3Djournal_Mode >>> i was told that it is faster and takes way less ram than gnu ld. >>> (which is not very surprising, given the quality of average gnu code) >> The tinycc linker is also buckets faster and less memory intensive than >> gnu ld. > > how about this one ? http://code.google.com/p/ucpp/ I haven't done a survey recently, but I do note the explosion of projects since gcc went GPLv3 and stopped being "good enough" for Apple or the BSDs or the Linux kernel developers or basically anybody except the FSF. I was working on tcc but there's clang and the new pcc and open64 and some kernel guys are gluing sparse to llvm... I expect gcc's days are numbered but displacing it is like displacing windows: it's an entrenched standard zealously defended by egocentric bastards out to impose Their Way upon the world, so there's work to do getting rid of it: http://flyingbynight.wordpress.com/2011/02/28/phnglui-mglw-nafh-cthuhu-riv-wgah-nagl-fhtag/ >> Too bad the maintainer of that project is a windows developer, >> if it would just DIE I'd restart my fork but I refuse to fight zombies >> without a cricket bat. > > hmm iirc the mob branch is the only active. it's not even that bad, i > checked it out lately and it built stuff which tcc 0.9.25 refused to build. My tree also built a lot of stuff 0.9.25 refused to build. That was sort of the point of my tree. >>>>> indeed, the more targets, the better. however i've seen in gcc's >>>>> changelog that >>>>> in the last releases some old architectures have been removed... >>>> Did I mention I think the FSF is really really bad at software >>>> engineering? >>>> >>> full ack. what sucks most tho are the build systems used by gnu. >>> i guess to fully grok gcc's build system you have to become Phd at the >>> gnu university. >> http://landley.net/notes-2010.html#11-11-2010 >> http://landley.net/notes-2010.html#15-10-2010 >> http://landley.net/notes-2010.html#26-08-2010 >> http://landley.net/notes-2010.html#20-08-2010 >> >> And so on, and so forth. Trust me: they don't understand it either. >> They just keep adding another special case for each new test case. >> >> Literally. That is the design of autoconf. >> > > interesting lecture. i actually think it would make sense to writeup a > "serious" blog post [web 2.0 like with comments and such] about > autoconf, with some examples like these here and link it on reddit. Eric Raymond and I had ideas for a paper on this, then we had a falling out because his libertarian views got co-opted by the very-merry-unbirthday crowd and now he's a climate change denialist, and really I don't want to get any of that on me. It's not the fun kind of crazy anymore. > compiling stuff could be so much fun if autoconf'd build systems > wouldn't always fuck everything up. Cross compiling would still suck. > actually it is so broken that it defeats the purpose of the FSF, in that > it makes it too hard to change and recompile your free software, making > it unfree that way. The FSF has been self defeating for many years. If you want a RANT: http://landley.net/notes-2010.html#17-07-2010 http://landley.net/notes-2010.html#19-07-2010 (First part is background necessary to understand the second part. I keep meaning to write a book on computer history, but I have too many other things to do...) >> You have to add said flag to the preprocessor as well, it sets a bunch >> of symbols telling you about your current target. Go: >> >> gcc -E -dM -< /dev/null | less >> >> Now do that for each of the cross compilers and diff the result. :) > > ... thats quite a list. Now ponder that list and go "hey, it tells me my current target and my current endianness... what is half of ./configure for, anyway?" Add in "what is libtool for", or the fact that pkg-config is so obviously stupid you can sum it up with stick figures http://xkcd.com/927/ (because rpm and dpkg and portage and pacman and bitbake and so on weren't _enough_), and PKG_CONFIG=/bin/true is a beautiful thing... >> I've learned not to try to fix FSF code, I've learned to lie to it >> and/or bypass large chunks of it instead. >> >> You've learned never to install Libtool on Linux, right? > > most stuff actually seems to come with its own libtool. > however i just found out that you have to delete *.la and magically > stuff builds, that failed earlier. Once upon a time I meant to do a libtool-stub that actually WOULD be a NOP successfully, like http://penma.de/code/gettext-stub/ and my little trick here: http://landley.net/hg/control-images/file/9/common/bootstrap/build-one-package.sh (lines 31-41). By the way, may I say that wordwrapping URLs is so far down on thunderbird's list of "appalling incompetence" it barely registers? I REALLY need to get a new mail program. (I just need a couple hours to set up all my filters again...) Anyway: I need to make a NOP libtool that I can symlink the others to, which just converts the command line arguments to ld format and does NOTHING ELSE. A small shell script, probably. Then ln -sf as needed. >>>>> (that's also a nice thing about musl, i report the bug and 10 minutes >>>>> later it is fixed, usually) >>>> Cool. I try to fix issues the same week they're reported (clearing my >>>> backlog on weekends), but don't always succeed. (I have a day job and >>>> working on this isn't it.) >>> (heh, you still didn't fix the busybox "patch program" bug with path >>> levels i reported on the busybox mailling list. >>> thats why sabotage uses gnu patch now ;)) >> Um, send me a link again? > > http://lists.busybox.net/pipermail/busybox/2011-July/076293.html Ah yes. I'll try to get to it this weekend. Rob 1318094858.0 From rob at landley.net Sat Oct 8 17:39:30 2011 From: rob at landley.net (Rob Landley) Date: Sat, 08 Oct 2011 12:39:30 -0500 Subject: [Aboriginal] Build error In-Reply-To: References: <4E8E245C.9050505@landley.net> Message-ID: <4E908AD2.6020004@landley.net> On 10/06/2011 11:49 PM, prasanna balan wrote: > > On 7 Oct 2011 03:27, "Rob Landley" > wrote: >> >> On 10/06/2011 09:18 AM, prasanna balan wrote: >> > I tried building aboriginal 1.1.0 and it broke during uClibc++ native >> > compiler...The last few lines of the build are as below: >> >> You just ran ./build.sh i686? >> > > Forgot to mention. It was. /build.sh i686 That's why the build outputs stuff like: >> > === ccwrap (i686 native-compiler) Identifying what it's currently doing. Part of the question was "did you run stages individually", "did you change lots of config" knobs, "did you skip host-tools.sh"... the usual. Your answer implies "no" to all that. > I tried with NO_CPLUSPLUS =1 and it built without break means some issue > with uclibc++ exists. > I use 32 bit slackware current with ext4 fs on /home I downloaded the slackware DVD and the kernel kept panicing when booted from the DVD under virtualbox on my work machine. I'm trying again on my netbook but it's a longish download... Rob 1318095570.0 From rob at landley.net Sat Oct 8 19:04:15 2011 From: rob at landley.net (Rob Landley) Date: Sat, 08 Oct 2011 14:04:15 -0500 Subject: [Aboriginal] aboriginal In-Reply-To: <4E8FE5EC.6010905@barfooze.de> References: <4E7E0A79.6060609@gmx.net> <4E7EB7A5.2040907@landley.net> <4E7F4B15.3030803@gmx.net> <4E81C278.3020707@landley.net> <4E89019F.6050808@gmx.net> <4E8B66BB.6060106@landley.net> <4E8CD86B.9010503@barfooze.de> <4E8DFFEF.2000404@landley.net> <4E8FE5EC.6010905@barfooze.de> Message-ID: <4E909EAF.3060009@landley.net> On 10/08/2011 12:55 AM, John Spencer wrote: >> Oh I'm mirroring all the gplv2 stuff (and possibly some bsd stuff) at >> http://landley.net/aboriginal/mirror >> >> I've spoken to Eben Moglen (co-author of both GPLv2 and GPLv3) about >> this when I visited the SFLC's office in New York (which was handling >> the busybox license enforcement lawsuits), and he _almost_ convinced me >> that GPLv3 wasn't worth opposing. > > indeed, seems to much effort, or leaves you behind with outdated sw... You just neatly summarized using Linux instead of windows on my laptop. And before that, OS/2... >> Computer history is a hobby of mine, and I wrote up some of the REAL >> history on this topic (as I understand it) last year: >> >> http://landley.net/notes-2010.html#17-07-2010 >> http://landley.net/notes-2010.html#19-07-2010 > > interesting read. > afaik unix systems were relatively uncommon here in europe and only got > popular with linux. > so you don't really learn about that kind of history. http://landley.net/history/mirror/ The Ken Olsen interview is great (might want to read the PDP-8 FAQ sections "What is a PDP" and "What is a PDP 8" first). Although if it's video you want, start with: http://www.youtube.com/watch?v=CFL9IyJ_qHk Based on Robert Cringely's book "accidental empires", which is great. (Doesn't cover unix, but it gives great context for the restof the industry". Steven Levy's book "Hackers" gives another important sub-plot, and Ken Olsen's interview is sort of "the other side of the story" of that book...) Don't get me started about computer history. It is a FASCINATING topic... >> That said, the third parties like Code Sourcery who actually write new >> code push that code upstream under the project's current license, and >> since the FSF successfully recaptured EGCS stuff like armv7 and >> microblaze support is either in external forks or only in newer versions >> of gcc/binutils after the gplv3 switch. And pcc and llvm/clang have a >> long way to go to build a workable Linux system even under x86... >> > oh, i actually expected clang to be mature enough to build the kernel. The kernel built _only_ with gcc for the longest time, and developed a lot of weird extensions and corner cases and dependencies on specific inlining behavior. They cleaned it up a bit, but so far only four toolchains I know of have built the kernel: 1) tccboot built a modified subset of 2.4 many years ago, but it was never reproduced and the project is essentially no longer maintained. 2) Intel's ICC built it (by implementing the necessary gcc extensions), but that's a proprietary x86-only compiler. 3) llvm/clang managed to build a fiddly subset of 2.6 (similar to tccboot) one year ago: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011711.html So LLVM is making lots of progress (due to Apple's sponsorship). I talked to the pcc guys about this a while back, google found this: http://www.mentby.com/rob-landley/project-proposal-add-pcc-support-for-linux-kernel.html But there was a thread on the pcc mailing list that went into more detail, i thought. Plus I linked to the recording of the OLS 2008 BOF I didn't _MEAN_ to spend "hosting" but they kept asking me questions and the camera _followed_ me when I wandered away from the front of the room... *shrug* Covered a lot of this material there, it was an hour. >> The FSF was threatening to sue this guy, which would have bankrupted him >> long before a verdict. >> > well, maybe, but they didn't sue him in the end. They'd already told him they would if he didn't fold. To quote Monty Python: "It's a nice army base you have here, colonel. Shame if something were to happen to it." "All those tanks. Very flammable." They don't actually have to set fire to a tank in order to be doing a shakedown. That's like saying "the guy who raped that woman at gunpoint didn't actually pull the trigger, therefore it was consensual"... >> Trust me, the FSF was talking out of its ass here. It led to me washing >> my hands of the SFLC: >> >> http;//landley.net/notes-2009.html#15-12-2009 >> > > interesting... That's why I stopped doing busybox license enforcement lawsuits, but there was also the fact that from an engineering perspective it was useless: we never got any code to add to the project. There wasn't any worth bothering with, ever. http://landley.net/notes-2001.html#15-08-2011 >> They did it because once again, they were utterly irrelevant and felt >> left out, so they struck out blindly to grab the spotlight. The end >> result was that CISCO DISSOLVED THE LINKSYS DIVISION AND GOT OUT OF >> LINUX DEVELOPMENT ENTIRELY. (Outsourced what they couldn't immediately >> kill to Red Hat, if I recall.) > > ok. thats somewhat unfortunate, if it really was only about the realtek > toolchain. Erik Andersen's father is a lawyer. He and harald welte and some other guys got together and browbeat Linksys' modified busybox and kernel source code out of them back in 2003: http://hardware.slashdot.org/story/03/07/06/2121234/linksys-releases-gpled-code-for-wrt54g That wasn't an official public lawsuit because A) nobody was quite sure it would win in court, B) they're expensive and protracted. Instead this was working behind the scenes to put pressure on Linksys, but it was "here's wha we could sue with". Yes, it's a bit like with Mepis, the fangs were bared without actually biting anybody. But they got a big payoff: open source embedded routers. Linksys used Linux in the first place because Pauline Middelink invented IP Masquerading on Linux (Cisco later renamed it "Network Address Translation" but we had it first). What Linksys brought to the table was cheap tiny hardware to run it on, in a simple "drop it in and it works" package. We wanted to run our code on that hardware, and to get their existing setup to modify we were willing to sue. This resulted in OpenWRT and OpenEmbedded and so on. (When Erik got the code he ported a uClibc-based debian to his router and ran busybox.net and uclibc.org on it for a bit, and also did buildroot.) But the downside of pressuring Linksys is that they stopped doing Linux development for about five years (outsourcing what they had to Taiwan and switching to some other embedded OS for most of their newer routers). They were just taking it back in house around 2008 when the FSF filed suit. The FSF lawsuit turned "ok, we got sued into compliance and now we're in the clear" into "we will never stop being sued over this piece of technology". And there was NO UPSIDE because there was NO CODE THEY HAD THAT ANYBODY ELSE CARED ABOUT. They _themselves_ didn't care about that old toolchain anymore, they were only still using that ancient gcc 3.x and linux 2.4 piece of crap because they hadn't been doing any development in that period, and were moving to gcc 4.x and linux 2.6 with vanilla unmodified versions of everything. I was there helping them make this transition, THAT was the project that got shut down by the FSF's blundering. Note that during this 5 year gap (between Linksys releasing source in 2003 and me visiting in 2008) the SFLC was formed, partly so Eben Moglen could get real world experience for his law sudents at NYU, and partly so he could distance himself from an increasingly insane and irrelevant RMS/FSF. As always, there's a lot going on behind the scenes, which the FSF either doesn't understand or is completely tone-deaf to, and they wind up doing more harm than good. (If this _wasn't_ the case, Linux would never have been needed, EGCS never would have happened, cygnus/codesourcery would be unnecessary, the SFLC would still just be the FSF's legal arm...) The FSF takes credit for things other people do and screws up the stuff they try to do in house. They're the reason Android has a policy "No GPL in userspace". (Probably due to their GPLv3 blundering specifically, but the policy pushes v2 out as well.) I was actually quite the fan of GPLv2, before v3 came out: http://sf.geekitude.com/content/pros-and-cons-gnu-general-public-license-linucon-2005 Rob 1318100655.0 From maillist-aboriginal at barfooze.de Sat Oct 8 22:43:10 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Sun, 09 Oct 2011 00:43:10 +0200 Subject: [Aboriginal] lsi_scsi: error In-Reply-To: <4E9075D3.4060704@landley.net> References: <4E8E72E8.30409@barfooze.de> <4E9075D3.4060704@landley.net> Message-ID: <4E90D1FE.7000808@barfooze.de> On 10/08/2011 06:09 PM, Rob Landley wrote: > On 10/06/2011 10:32 PM, John Spencer wrote: >> on the previous version of aboriginal (1.01 ?) armv6l (didn't test 1.1 >> yet), >> >> i keep getting the following error/warning, when compiling big stuff, or >> even while extracting gcc 4.5.3 core's tarball (xf only). >> lsi_scsi: error: ORDERED queue not implemented > Huh. I don't remember that. It sounds like a kernel issue, some kind > of mismatch between the scsi driver and either the block elevator or > something, but I haven't seen it... > > Neither did "find . -type f | xargs grep lsi_scsi" in the current linux > kernel git repo. > >> despite the "error", it seems everything works, however it's kinda >> annoying. >> is that a bug in aboriginal or in my local qemu install ? > Ah, there you go. Doing the find in the qemu source pulls up file > hw/lsi53c895a.c containing: > > #define BADF(fmt, ...) \ > do { fprintf(stderr, "lsi_scsi: error: " fmt , ## __VA_ARGS__);} while (0) > #endif > ... > case 0x22: /* ORDERED queue */ > BADF("ORDERED queue not implemented\n"); > s->select_tag |= lsi_get_msgbyte(s) | LSI_TAG_VALID; > break; > ah, thanks for your research. this time it's gotten nasty: 2011.09.08 22:08:05 building binutils lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented sd 0:0:1:0: [sdb] ABORT operation started sd 0:0:1:0: ABORT operation failed. sd 0:0:1:0: [sdb] DEVICE RESET operation started scsi target0:0:1: control msgout: c. lsi_scsi: error: Unimplemented message 0x0c scsi target0:0:1: has been reset sd 0:0:1:0: DEVICE RESET operation complete. sd 0:0:1:0: M_REJECT received (0:0). lsi_scsi: error: ORDERED queue not implemented lsi_scsi: error: ORDERED queue not implemented 2011.09.08 22:24:29 done. possibly there is some kernel switch which could be used to disable usage of "ORDERED queue" everything seems to work, but possibly it can get still worse. i guess it's better to disable it until qemu supports it... > The messages come from qemu. Might want to poke their mailing list > about it. > > Since it's going to stderr, you could try running qemu with 2>/dev/null > (since everything written to the linux console goes to the emulator's > stdout, and thus anything qemu writes to stderr can't have come from > Linux. Even if Linux internally wrote it to stderr. :) > >> "QEMU emulator version 0.13.91, Copyright (c) 2003-2008 Fabrice Bellard" > I note that 0.15.0 is out. Doesn't look like it fixes this bug, though. i'm actually glad that aboriginal comes with the comfortable qemu start environment, so that i don't have to mess around with qemu myself... (yet another tool to master) > Rob > 1318113790.0 From prazzb at gmail.com Sun Oct 9 13:30:42 2011 From: prazzb at gmail.com (prasanna balan) Date: Sun, 9 Oct 2011 19:00:42 +0530 Subject: [Aboriginal] Build error In-Reply-To: <4E908AD2.6020004@landley.net> References: <4E8E245C.9050505@landley.net> <4E908AD2.6020004@landley.net> Message-ID: On Sat, Oct 8, 2011 at 11:09 PM, Rob Landley wrote: > On 10/06/2011 11:49 PM, prasanna balan wrote: >> >> On 7 Oct 2011 03:27, "Rob Landley" > > wrote: >>> >>> On 10/06/2011 09:18 AM, prasanna balan wrote: >>> > I tried building aboriginal 1.1.0 and it broke during uClibc++ native >>> > compiler...The last few lines of the build are as below: >>> >>> You just ran ./build.sh i686? >>> >> >> Forgot to mention. It was. /build.sh i686 > > That's why the build outputs stuff like: > >>> > === ccwrap (i686 native-compiler) > > Identifying what it's currently doing. ?Part of the question was "did > you run stages individually", "did you change lots of config" knobs, > "did you skip host-tools.sh"... ?the usual. ?Your answer implies "no" to > all that. > >> I tried with NO_CPLUSPLUS =1 and it built without break means some issue >> with uclibc++ exists. >> I use 32 bit slackware current with ext4 fs on /home > > I downloaded the slackware DVD and the kernel kept panicing when booted > from the DVD under virtualbox on my work machine. ?I'm trying again on > my netbook but it's a longish download... > > Rob > I tried it again and it broke again with the same errors (that's obvious)..This time I ran more/record-commands.sh and redid the build. Details are as below: =================================================== $ cat build/logs/cmdlines.i686.native-compiler.uClibc++ make "defconfig" gcc "-Os" "-S" "-o" "/dev/null" "-xc" "/dev/null" gcc "-print-libgcc-file-name" cut "-c1" gcc "-dumpversion" grep "-q" "as-needed" ld "--help" cut "-c1" gcc "-dumpversion" make "-C" "extra/config" "conf" $ ================================================== This specifically means that the recursive make breaks due to some unknown reason.Hope this helps in debugging. -prazzb 1318167042.0 From rob at landley.net Sun Oct 9 21:09:06 2011 From: rob at landley.net (Rob Landley) Date: Sun, 09 Oct 2011 16:09:06 -0500 Subject: [Aboriginal] lsi_scsi: error In-Reply-To: <4E90D1FE.7000808@barfooze.de> References: <4E8E72E8.30409@barfooze.de> <4E9075D3.4060704@landley.net> <4E90D1FE.7000808@barfooze.de> Message-ID: <4E920D72.6000900@landley.net> On 10/08/2011 05:43 PM, John Spencer wrote: > On 10/08/2011 06:09 PM, Rob Landley wrote: >> On 10/06/2011 10:32 PM, John Spencer wrote: >>> on the previous version of aboriginal (1.01 ?) armv6l (didn't test 1.1 >>> yet), >>> >>> i keep getting the following error/warning, when compiling big stuff, or >>> even while extracting gcc 4.5.3 core's tarball (xf only). >>> lsi_scsi: error: ORDERED queue not implemented >> Huh. I don't remember that. It sounds like a kernel issue, some kind >> of mismatch between the scsi driver and either the block elevator or >> something, but I haven't seen it... >> >> Neither did "find . -type f | xargs grep lsi_scsi" in the current linux >> kernel git repo. >> >>> despite the "error", it seems everything works, however it's kinda >>> annoying. >>> is that a bug in aboriginal or in my local qemu install ? >> Ah, there you go. Doing the find in the qemu source pulls up file >> hw/lsi53c895a.c containing: >> >> #define BADF(fmt, ...) \ >> do { fprintf(stderr, "lsi_scsi: error: " fmt , ## __VA_ARGS__);} while >> (0) >> #endif >> ... >> case 0x22: /* ORDERED queue */ >> BADF("ORDERED queue not implemented\n"); >> s->select_tag |= lsi_get_msgbyte(s) | LSI_TAG_VALID; >> break; >> > > ah, thanks for your research. > > this time it's gotten nasty: > 2011.09.08 22:08:05 building binutils > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > sd 0:0:1:0: [sdb] ABORT operation started > sd 0:0:1:0: ABORT operation failed. > sd 0:0:1:0: [sdb] DEVICE RESET operation started > scsi target0:0:1: control msgout: c. > lsi_scsi: error: Unimplemented message 0x0c > scsi target0:0:1: has been reset > sd 0:0:1:0: DEVICE RESET operation complete. > sd 0:0:1:0: M_REJECT received (0:0). > lsi_scsi: error: ORDERED queue not implemented > lsi_scsi: error: ORDERED queue not implemented > 2011.09.08 22:24:29 done. > > possibly there is some kernel switch which could be used to disable > usage of "ORDERED queue" Apparently the qemu guys have been poking at this: http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg02307.html http://lists.gnu.org/archive/html/qemu-devel/2010-09/msg01225.html Honestly, they're the people you need to talk to. > everything seems to work, but possibly it can get still worse. > i guess it's better to disable it until qemu supports it... I'm open to kernel .config changes for the armv6l target. Currently the board localization in sources/targets/armv6l is: LINUX_CONFIG=" # Processor config CONFIG_CPU_V6=y CONFIG_MMU=y CONFIG_ARM_THUMB=y CONFIG_AEABI=y CONFIG_VFP=y # Versatile board CONFIG_ARCH_VERSATILE_PB=y CONFIG_PCI_LEGACY=y CONFIG_SERIAL_NONSTANDARD=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y CONFIG_RTC_DRV_PL031=y CONFIG_SCSI_SYM53C8XX_2=y CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 CONFIG_SCSI_SYM53C8XX_MMIO=y " If you see any symbols that should be removed from or added to that... >>> "QEMU emulator version 0.13.91, Copyright (c) 2003-2008 Fabrice Bellard" >> I note that 0.15.0 is out. Doesn't look like it fixes this bug, though. > > i'm actually glad that aboriginal comes with the comfortable qemu start > environment, > so that i don't have to mess around with qemu myself... (yet another > tool to master) Agreed, that's why I put the wrapper scripts there. Have you tried the: ./dev-environment.sh 2>/dev/null workaround yet? What's only going to discard error messages _from_qemu_, which seems like what you want... Rob 1318194546.0 From maillist-aboriginal at barfooze.de Mon Oct 10 01:08:13 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Mon, 10 Oct 2011 03:08:13 +0200 Subject: [Aboriginal] lsi_scsi: error In-Reply-To: <4E920D72.6000900@landley.net> References: <4E8E72E8.30409@barfooze.de> <4E9075D3.4060704@landley.net> <4E90D1FE.7000808@barfooze.de> <4E920D72.6000900@landley.net> Message-ID: <4E92457D.1070600@barfooze.de> On 10/09/2011 11:09 PM, Rob Landley wrote: > On 10/08/2011 05:43 PM, John Spencer wrote: >> On 10/08/2011 06:09 PM, Rob Landley wrote: >>> On 10/06/2011 10:32 PM, John Spencer wrote: >>>> on the previous version of aboriginal (1.01 ?) armv6l (didn't test 1.1 >>>> yet), >>>> >>>> i keep getting the following error/warning, when compiling big stuff, or >>>> even while extracting gcc 4.5.3 core's tarball (xf only). >>>> lsi_scsi: error: ORDERED queue not implemented >>> Huh. I don't remember that. It sounds like a kernel issue, some kind >>> of mismatch between the scsi driver and either the block elevator or >>> something, but I haven't seen it... >>> >>> Neither did "find . -type f | xargs grep lsi_scsi" in the current linux >>> kernel git repo. >>> >>>> despite the "error", it seems everything works, however it's kinda >>>> annoying. >>>> is that a bug in aboriginal or in my local qemu install ? >>> Ah, there you go. Doing the find in the qemu source pulls up file >>> hw/lsi53c895a.c containing: >>> >>> #define BADF(fmt, ...) \ >>> do { fprintf(stderr, "lsi_scsi: error: " fmt , ## __VA_ARGS__);} while >>> (0) >>> #endif >>> ... >>> case 0x22: /* ORDERED queue */ >>> BADF("ORDERED queue not implemented\n"); >>> s->select_tag |= lsi_get_msgbyte(s) | LSI_TAG_VALID; >>> break; >>> >> ah, thanks for your research. >> >> this time it's gotten nasty: >> 2011.09.08 22:08:05 building binutils >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> sd 0:0:1:0: [sdb] ABORT operation started >> sd 0:0:1:0: ABORT operation failed. >> sd 0:0:1:0: [sdb] DEVICE RESET operation started >> scsi target0:0:1: control msgout: c. >> lsi_scsi: error: Unimplemented message 0x0c >> scsi target0:0:1: has been reset >> sd 0:0:1:0: DEVICE RESET operation complete. >> sd 0:0:1:0: M_REJECT received (0:0). >> lsi_scsi: error: ORDERED queue not implemented >> lsi_scsi: error: ORDERED queue not implemented >> 2011.09.08 22:24:29 done. >> >> possibly there is some kernel switch which could be used to disable >> usage of "ORDERED queue" > Apparently the qemu guys have been poking at this: > > http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg02307.html > http://lists.gnu.org/archive/html/qemu-devel/2010-09/msg01225.html > > Honestly, they're the people you need to talk to. > thanks, it is no real problem; everything works despite that. won't bother you anymore. >> everything seems to work, but possibly it can get still worse. >> i guess it's better to disable it until qemu supports it... > I'm open to kernel .config changes for the armv6l target. Currently the > board localization in sources/targets/armv6l is: > > LINUX_CONFIG=" > > # Processor config > > CONFIG_CPU_V6=y > CONFIG_MMU=y > CONFIG_ARM_THUMB=y > CONFIG_AEABI=y > CONFIG_VFP=y > > # Versatile board > > CONFIG_ARCH_VERSATILE_PB=y > CONFIG_PCI_LEGACY=y > CONFIG_SERIAL_NONSTANDARD=y > CONFIG_SERIAL_AMBA_PL011=y > CONFIG_SERIAL_AMBA_PL011_CONSOLE=y > CONFIG_RTC_DRV_PL031=y > CONFIG_SCSI_SYM53C8XX_2=y > CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 > CONFIG_SCSI_SYM53C8XX_MMIO=y > " > funny, i just c/p'ed that part a few hours earlier into sabotage's kernel build script... btw, do you happen to know by chance why the kernel make disrespects my CC/HOSTCC settings and uses gcc instead of distcc ? > If you see any symbols that should be removed from or added to that... > will keep my eyes open. >>>> "QEMU emulator version 0.13.91, Copyright (c) 2003-2008 Fabrice Bellard" >>> I note that 0.15.0 is out. Doesn't look like it fixes this bug, though. >> i'm actually glad that aboriginal comes with the comfortable qemu start >> environment, >> so that i don't have to mess around with qemu myself... (yet another >> tool to master) > Agreed, that's why I put the wrapper scripts there. > > Have you tried the: > > ./dev-environment.sh 2>/dev/null > > workaround yet? What's only going to discard error messages > _from_qemu_, which seems like what you want... not yet. will try later once the kernel is built. since it builds since about 2.5 hours, i guess it will finish soon... hopefully. > Rob > 1318208893.0 From maillist-aboriginal at barfooze.de Mon Oct 10 06:14:20 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Mon, 10 Oct 2011 08:14:20 +0200 Subject: [Aboriginal] lsi_scsi: error In-Reply-To: <4E92457D.1070600@barfooze.de> References: <4E8E72E8.30409@barfooze.de> <4E9075D3.4060704@landley.net> <4E90D1FE.7000808@barfooze.de> <4E920D72.6000900@landley.net> <4E92457D.1070600@barfooze.de> Message-ID: <4E928D3C.3050809@barfooze.de> On 10/10/2011 03:08 AM, John Spencer wrote: > > btw, do you happen to know by chance why the kernel make disrespects > my CC/HOSTCC settings and uses gcc instead of distcc ? nevermind, it seems the only way is to mess with the makefile, if you dont happen to use the usual prefixed crosstoolchain. 1318227260.0 From rob at landley.net Mon Oct 10 17:35:39 2011 From: rob at landley.net (Rob Landley) Date: Mon, 10 Oct 2011 12:35:39 -0500 Subject: [Aboriginal] lsi_scsi: error In-Reply-To: <4E928D3C.3050809@barfooze.de> References: <4E8E72E8.30409@barfooze.de> <4E9075D3.4060704@landley.net> <4E90D1FE.7000808@barfooze.de> <4E920D72.6000900@landley.net> <4E92457D.1070600@barfooze.de> <4E928D3C.3050809@barfooze.de> Message-ID: <4E932CEB.5090307@landley.net> On 10/10/2011 01:14 AM, John Spencer wrote: > On 10/10/2011 03:08 AM, John Spencer wrote: >> >> btw, do you happen to know by chance why the kernel make disrespects >> my CC/HOSTCC settings and uses gcc instead of distcc ? > > nevermind, it seems the only way is to mess with the makefile, if you > dont happen to use the usual prefixed crosstoolchain. Make is horrible, here's how bits of the horror work: Environment variables become the default values of make variables when make starts, but there are two forms of assignment in make: ?= leaves a variable alone if it already has a value, = overwrites unconditionally. Make developers tend to use the = without thinking about it. To overcome this, variables assigned on the make command line become read-only and cannot be overridden by make assignments. (The assignments are ignored.) Thus you specify your architecture and cross compiler on the command line, not in environment variables. Then we get into recursive make, which is an abomination: http://aegis.sourceforge.net/auug97.pdf And really, the whole of make has outlived its usefulness, but I've ranted about that here (at length) before: http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000165.html Rob 1318268139.0 From rob at landley.net Mon Oct 10 17:49:16 2011 From: rob at landley.net (Rob Landley) Date: Mon, 10 Oct 2011 12:49:16 -0500 Subject: [Aboriginal] lsi_scsi: error In-Reply-To: <4E92457D.1070600@barfooze.de> References: <4E8E72E8.30409@barfooze.de> <4E9075D3.4060704@landley.net> <4E90D1FE.7000808@barfooze.de> <4E920D72.6000900@landley.net> <4E92457D.1070600@barfooze.de> Message-ID: <4E93301C.2090008@landley.net> On 10/09/2011 08:08 PM, John Spencer wrote: >>> possibly there is some kernel switch which could be used to disable >>> usage of "ORDERED queue" >> Apparently the qemu guys have been poking at this: >> >> http://lists.gnu.org/archive/html/qemu-devel/2011-04/msg02307.html >> http://lists.gnu.org/archive/html/qemu-devel/2010-09/msg01225.html >> >> Honestly, they're the people you need to talk to. >> > thanks, it is no real problem; everything works despite that. > won't bother you anymore. It's not a bother, it's just an "I can't help with this in the time I have available right now". I don't understand the guts of SCSI all that well, mostly due to despising the way scsi bigots keep trying to rout even ramdisks through the scsi midlayer. >>> everything seems to work, but possibly it can get still worse. >>> i guess it's better to disable it until qemu supports it... >> I'm open to kernel .config changes for the armv6l target. Currently the >> board localization in sources/targets/armv6l is: >> >> LINUX_CONFIG=" >> >> # Processor config >> >> CONFIG_CPU_V6=y >> CONFIG_MMU=y >> CONFIG_ARM_THUMB=y >> CONFIG_AEABI=y >> CONFIG_VFP=y >> >> # Versatile board >> >> CONFIG_ARCH_VERSATILE_PB=y >> CONFIG_PCI_LEGACY=y >> CONFIG_SERIAL_NONSTANDARD=y >> CONFIG_SERIAL_AMBA_PL011=y >> CONFIG_SERIAL_AMBA_PL011_CONSOLE=y >> CONFIG_RTC_DRV_PL031=y >> CONFIG_SCSI_SYM53C8XX_2=y >> CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0 >> CONFIG_SCSI_SYM53C8XX_MMIO=y >> " >> > > funny, i just c/p'ed that part a few hours earlier into sabotage's > kernel build script... You read http://landley.net/aboriginal/FAQ.html#dev_miniconfig already, right? >> Have you tried the: >> >> ./dev-environment.sh 2>/dev/null >> >> workaround yet? What's only going to discard error messages >> _from_qemu_, which seems like what you want... > > not yet. will try later once the kernel is built. since it builds since > about 2.5 hours, i guess it will finish soon... hopefully. Good luck, Rob 1318268956.0 From maillist-aboriginal at barfooze.de Wed Oct 12 04:43:47 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Wed, 12 Oct 2011 06:43:47 +0200 Subject: [Aboriginal] lsi_scsi: error In-Reply-To: <4E932CEB.5090307@landley.net> References: <4E8E72E8.30409@barfooze.de> <4E9075D3.4060704@landley.net> <4E90D1FE.7000808@barfooze.de> <4E920D72.6000900@landley.net> <4E92457D.1070600@barfooze.de> <4E928D3C.3050809@barfooze.de> <4E932CEB.5090307@landley.net> Message-ID: <4E951B03.2070500@barfooze.de> On 10/10/2011 07:35 PM, Rob Landley wrote: > On 10/10/2011 01:14 AM, John Spencer wrote: >> On 10/10/2011 03:08 AM, John Spencer wrote: >>> btw, do you happen to know by chance why the kernel make disrespects >>> my CC/HOSTCC settings and uses gcc instead of distcc ? >> nevermind, it seems the only way is to mess with the makefile, if you >> dont happen to use the usual prefixed crosstoolchain. > Make is horrible, here's how bits of the horror work: > > Environment variables become the default values of make variables when > make starts, but there are two forms of assignment in make: ?= leaves a > variable alone if it already has a value, = overwrites unconditionally. > Make developers tend to use the = without thinking about it. > > To overcome this, variables assigned on the make command line become > read-only and cannot be overridden by make assignments. (The > assignments are ignored.) Thus you specify your architecture and cross > compiler on the command line, not in environment variables. thanks for the explanation. using make dep; make -j4 CC=distcc i could finally get the kernel to use distcc... however it compiles since more than 26 hours. the distcc threads on the host are rarely doing some work. it seems the bottleneck is the cpp work done on the qemu vm. google has targeted this weakness in their "pump mode" addition to distcc, but that is unfortunately written in *python*. it seems nobody, and especially not big corporations, cares about portability any more. > Then we get into recursive make, which is an abomination: > > http://aegis.sourceforge.net/auug97.pdf > > And really, the whole of make has outlived its usefulness, but I've > ranted about that here (at length) before: > > http://lists.landley.net/pipermail/aboriginal-landley.net/2011-June/000165.html lol, that sounds familiar. apart from its syntax which is even harder to learn than perl, make is not that bad imo... at least it is available on nearly all systems and compiles without patches, and is relatively powerful. once you copy/pasted together your first working makefile, you can reuse that relatively well.... of course i could imagine a better solution, but hey, most of the rest is much worse ;) > Rob > 1318394627.0 From maillist-aboriginal at barfooze.de Wed Oct 12 05:35:22 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Wed, 12 Oct 2011 07:35:22 +0200 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E90880A.8040104@landley.net> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> <4E8E7669.7040502@landley.net> <4E8FDD7C.9000607@barfooze.de> <4E90880A.8040104@landley.net> Message-ID: <4E95271A.9030604@barfooze.de> On 10/08/2011 07:27 PM, Rob Landley wrote: > On 10/08/2011 12:19 AM, John Spencer wrote: > >> here's a writeup from the amd64 port: >> http://brightrain.aerifal.cx/~niklata/PORTING >> >> this commit here documents about everything needed for the arm port >> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=d960d4f2cbf18ff3476c7ac03698ec253885dd8e >> >> >> and these two here add dynamic linking to musl arm >> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=12ace5bf76040e928df1abd57e9b5134ca4647c6 >> >> http://git.etalabs.net/cgi-bin/gitweb.cgi?p=musl;a=commitdiff;h=fcaf7065698bce12a444803587421ae88446f6c0 >> >> >> see how little code was needed... > Cool. > > I note that uClibc currently has no s390 support, but these days QEMU > _does_. This means I can't support all the QEMU targets using uClibc > unless their development community gets fundamentally unstuck. > > If musl supported that target and uClibc didn't, I'd logically want to > see about getting musl support into aboriginal itself. as it looks currently, you'd have to make that port yourself ;) actually the arm port has just been finished and as it looks i'm currently the only using/testing it... i'd expect mips/ppc support coming next, *if* some other ports will happen in the near future. > (This would mean > at minimum building current busybox against it, plus an older GPLv2 > release of a gnu toolchain (gcc 4.2.1, binutils-1.17, and make 3.81 were > the last GPLv2 releases, and bash 2.05b is "good enough" about about 1/3 > the size of modern bash.) make 3.81 has the additional advantage that it builds older kernels as well, since some breaking change has been introduced with make 3.82 (for example linux 2.6.25 won't build on 3.82) the binutils however are too old to play nice with musl. > The rest of the packages used during the aboriginal linux build are > distcc, e2fsprogs, genext2fs, and squashfs (which requires zlib). (And > of course current linux but it doesn't depend on libc.) is aufs enabled as well ? i thought about adding support for that to my build manager, as it turned out that decompressing the kernel each time i build it eats a lot of time (about 10 minutes in qemu). doing the untaring in a separate step and overlay it with a build-only directory would allow simply trashing the built stuff and restart clean without having to untar again (since "make clean" won't remove patches, and so on). >>> (In aboriginal, all the information about a specific target is in the >>> sources/targets files, one per target. At one point many moons ago i >>> had documentation about adding a new target. um... >>> http://landley.net/aboriginal/documentation.html#new_target I think. >>> Wow that's out of date...) > I need at least a month to do nothing but documentation, but I know from > experience it wouldn't be enough. > the aboriginal infrastructure is indeed pretty sweet and i was thinking about wether i should adopt parts of it. especially the automatic distcc configuration, although the preprocessing power needed for some stuff makes it nearly useless in those cases. if that bottleneck could be removed, it would even make sense to allow to add more distcc-servers. well, maybe some day a sane person (which happens to know python) will come and port the distcc pump stuff to C, or just rewrite it from scratch. >>>>> This is different from the attempts to port bionic to the vanilla >>>>> kernel, has no relation to klibc, is not related to uClibc, dietlibc, >>>>> glibc, libc5, or any of the BSD libc projects? >>>>> >>>> yep, different attempt. and so far it's looking very sweet. couldn't do >>>> it better myself. >>>> completeness status is reflected in the version number which is 0.8.xx >>>> there's some C99 math stuff missing and no C++ support yet, but apart >>>> from that nearly everything compiles now >>> Why should libc care about c++ again? C++ is not C, any more than >>> Objective C is. Java borrowed a lot of C's syntax, and isn't C either. >>> >> indeed, i actually would prefer a system without any C++ crap. > NO_CPLUSPLUS=1 does it for aboriginal, but people keep writing stuff in > it... > >> however there are many useful apps written in it (like gold), and to get >> wide acceptance musl has to get some way to build C++ stuff. it's >> unlikely that the GCC guys will do it... > You're aware of uClibc++, right? (My project builds it and all. :) > It's a bit stalled right now, but I have Garret's phone number around > here somewhere... > > What's needed _in_ the libc? Stack unwinding cruft? > > from what i've heard there's special atexit/dynlink stuff needed and partially some symbol names clash. currently there's some discussion about that on the musl mailinglist. >>> In theory, the system images I built and posted have working c++ >>> toolchains in them, based on uClibc+=. Haven't stressed it much, but it >>> builds hello world with the funky "we redefined the bit shift operators >>> to perform I/O" stuff. >>> >>> (It died building cmake, I have to go back and work out why...) >>> >> not really in the mood to fight with C++ code currently. > Neither am I. That's why it's been on my todo list for over a year. > >> btw, i could compile gcc 4.5.3 by passing -Wl,--no-keep-memory to the >> linker. >> i also added a patch which disables target-libiberty and target-libz. >> with disable-bootstrap the compiler built in around 15 minutes using >> distcc o.0 >> so it actually looks as if --no-keep-memory actually is *faster* despite >> being described as "slow but less memory hungry" > The FSF remains crazy, although sometimes performance stuff is non-obvious: > > http://www.funtoo.org/wiki/Funtoo_Filesystem_Guide,_Part_5#data.3Djournal_Mode > indeed. >>>> i was told that it is faster and takes way less ram than gnu ld. >>>> (which is not very surprising, given the quality of average gnu code) >>> The tinycc linker is also buckets faster and less memory intensive than >>> gnu ld. >> how about this one ? http://code.google.com/p/ucpp/ actually that is a *preprocessor*... we were talking about ripping out the tcc preprocessor somewhere else... > I haven't done a survey recently, but I do note the explosion of > projects since gcc went GPLv3 and stopped being "good enough" for Apple > or the BSDs or the Linux kernel developers or basically anybody except > the FSF. I was working on tcc but there's clang and the new pcc and > open64 and some kernel guys are gluing sparse to llvm... > > I expect gcc's days are numbered but displacing it is like displacing > windows: it's an entrenched standard zealously defended by egocentric > bastards out to impose Their Way upon the world, so there's work to do > getting rid of it: > > http://flyingbynight.wordpress.com/2011/02/28/phnglui-mglw-nafh-cthuhu-riv-wgah-nagl-fhtag/ > i was looking lately at the tendra compiler, which has just been uploaded to https://bitbucket.org/asmodai/tendra/ that seems like a well designed compiler with good optimization potential. it uses some internal intermediate format (which is even standardized), which then gets optimized according to the target. however the build system is pretty outdated and i was unable to bootstrap it in its current state. i hope some activity on that project will start soon... >>> Too bad the maintainer of that project is a windows developer, >>> if it would just DIE I'd restart my fork but I refuse to fight zombies >>> without a cricket bat. >> hmm iirc the mob branch is the only active. it's not even that bad, i >> checked it out lately and it built stuff which tcc 0.9.25 refused to build. > My tree also built a lot of stuff 0.9.25 refused to build. That was > sort of the point of my tree. really unfortunate that you stopped it. but i have read your statement and respect your reasons. in the meantime, an uncoordinated "mob" drives the project on repo.or.cz ;) >>>>>> indeed, the more targets, the better. however i've seen in gcc's >>>>>> changelog that >>>>>> in the last releases some old architectures have been removed... >>>>> Did I mention I think the FSF is really really bad at software >>>>> engineering? >>>>> >>>> full ack. what sucks most tho are the build systems used by gnu. >>>> i guess to fully grok gcc's build system you have to become Phd at the >>>> gnu university. >>> http://landley.net/notes-2010.html#11-11-2010 >>> http://landley.net/notes-2010.html#15-10-2010 >>> http://landley.net/notes-2010.html#26-08-2010 >>> http://landley.net/notes-2010.html#20-08-2010 >>> >>> And so on, and so forth. Trust me: they don't understand it either. >>> They just keep adding another special case for each new test case. >>> >>> Literally. That is the design of autoconf. >>> >> interesting lecture. i actually think it would make sense to writeup a >> "serious" blog post [web 2.0 like with comments and such] about >> autoconf, with some examples like these here and link it on reddit. > Eric Raymond and I had ideas for a paper on this, then we had a falling > out because his libertarian views got co-opted by the > very-merry-unbirthday crowd and now he's a climate change denialist, and > really I don't want to get any of that on me. It's not the fun kind of > crazy anymore. > >> compiling stuff could be so much fun if autoconf'd build systems >> wouldn't always fuck everything up. > Cross compiling would still suck. > >> actually it is so broken that it defeats the purpose of the FSF, in that >> it makes it too hard to change and recompile your free software, making >> it unfree that way. > The FSF has been self defeating for many years. If you want a RANT: > > http://landley.net/notes-2010.html#17-07-2010 > http://landley.net/notes-2010.html#19-07-2010 > > (First part is background necessary to understand the second part. I > keep meaning to write a book on computer history, but I have too many > other things to do...) > the mail from rms about "making the code hard to use" to get evil companies out is indeed shocking. it seems GNU software sucks by design. >>> You have to add said flag to the preprocessor as well, it sets a bunch >>> of symbols telling you about your current target. Go: >>> >>> gcc -E -dM -< /dev/null | less >>> >>> Now do that for each of the cross compilers and diff the result. :) >> ... thats quite a list. > Now ponder that list and go "hey, it tells me my current target and my > current endianness... what is half of ./configure for, anyway?" indeed. > Add in > "what is libtool for", or the fact that pkg-config is so obviously > stupid you can sum it up with stick figures http://xkcd.com/927/ > (because rpm and dpkg and portage and pacman and bitbake and so on > weren't _enough_), and PKG_CONFIG=/bin/true is a beautiful thing... > PKG_CONFIG=/bin/true<- that actually works ? >>> I've learned not to try to fix FSF code, I've learned to lie to it >>> and/or bypass large chunks of it instead. >>> >>> You've learned never to install Libtool on Linux, right? >> most stuff actually seems to come with its own libtool. >> however i just found out that you have to delete *.la and magically >> stuff builds, that failed earlier. > Once upon a time I meant to do a libtool-stub that actually WOULD be a > NOP successfully, like http://penma.de/code/gettext-stub/ and my little > trick here: > > http://landley.net/hg/control-images/file/9/common/bootstrap/build-one-package.sh > (lines 31-41). "Autoconf is useless" ;) > By the way, may I say that wordwrapping URLs is so far down on > thunderbird's list of "appalling incompetence" it barely registers? I > REALLY need to get a new mail program. (I just need a couple hours to > set up all my filters again...) > > Anyway: I need to make a NOP libtool that I can symlink the others to, > which just converts the command line arguments to ld format and does > NOTHING ELSE. A small shell script, probably. Then ln -sf as needed. i shall appreciate it as well. >>>>>> (that's also a nice thing about musl, i report the bug and 10 minutes >>>>>> later it is fixed, usually) >>>>> Cool. I try to fix issues the same week they're reported (clearing my >>>>> backlog on weekends), but don't always succeed. (I have a day job and >>>>> working on this isn't it.) >>>> (heh, you still didn't fix the busybox "patch program" bug with path >>>> levels i reported on the busybox mailling list. >>>> thats why sabotage uses gnu patch now ;)) >>> Um, send me a link again? >> http://lists.busybox.net/pipermail/busybox/2011-July/076293.html > Ah yes. I'll try to get to it this weekend. thanks for the patch. will test it as soon as the kernel compile is finished... > Rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maillist-aboriginal at barfooze.de Wed Oct 12 21:05:41 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Wed, 12 Oct 2011 23:05:41 +0200 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E95271A.9030604@barfooze.de> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> <4E8E7669.7040502@landley.net> <4E8FDD7C.9000607@barfooze.de> <4E90880A.8040104@landley.net> <4E95271A.9030604@barfooze.de> Message-ID: <4E960125.6080706@barfooze.de> On 10/12/2011 07:35 AM, John Spencer wrote: > > > the aboriginal infrastructure is indeed pretty sweet and i was > thinking about wether i should adopt parts of it. > especially the automatic distcc configuration, although the > preprocessing power needed for some stuff makes it nearly useless in > those cases. if that bottleneck could be removed, it would even make > sense to allow to add more distcc-servers. > well, maybe some day a sane person (which happens to know python) will > come and port the distcc pump stuff to C, or just rewrite it from > scratch. actually the problem was mktimeconst.c which looped forever due to a bug (1L vs 1LL)... i have taken the patch (linux-noperl-timeconst.patch) from another source which wasn't fixed yet... builds in about 30 minutes now. 1318453541.0 From rob at landley.net Thu Oct 13 00:18:56 2011 From: rob at landley.net (Rob Landley) Date: Wed, 12 Oct 2011 19:18:56 -0500 Subject: [Aboriginal] lsi_scsi: error In-Reply-To: <4E951B03.2070500@barfooze.de> References: <4E8E72E8.30409@barfooze.de> <4E9075D3.4060704@landley.net> <4E90D1FE.7000808@barfooze.de> <4E920D72.6000900@landley.net> <4E92457D.1070600@barfooze.de> <4E928D3C.3050809@barfooze.de> <4E932CEB.5090307@landley.net> <4E951B03.2070500@barfooze.de> Message-ID: <4E962E70.1010605@landley.net> On 10/11/2011 11:43 PM, John Spencer wrote: > On 10/10/2011 07:35 PM, Rob Landley wrote: >> On 10/10/2011 01:14 AM, John Spencer wrote: >>> On 10/10/2011 03:08 AM, John Spencer wrote: >>>> btw, do you happen to know by chance why the kernel make disrespects >>>> my CC/HOSTCC settings and uses gcc instead of distcc ? >>> nevermind, it seems the only way is to mess with the makefile, if you >>> dont happen to use the usual prefixed crosstoolchain. >> Make is horrible, here's how bits of the horror work: >> >> Environment variables become the default values of make variables when >> make starts, but there are two forms of assignment in make: ?= leaves a >> variable alone if it already has a value, = overwrites unconditionally. >> Make developers tend to use the = without thinking about it. >> >> To overcome this, variables assigned on the make command line become >> read-only and cannot be overridden by make assignments. (The >> assignments are ignored.) Thus you specify your architecture and cross >> compiler on the command line, not in environment variables. > > thanks for the explanation. using make dep; make -j4 CC=distcc i could > finally get the kernel to use distcc... > however it compiles since more than 26 hours. the distcc threads on the > host are rarely doing some work. Huh, it really shouldn't take that long. (Although the distcc host threads usually complete quickly enough that it doesn't look like they're doing much.) That said, I'm having some performance problems on my laptop where native builds under qemu aren't working as fast as they used to. Trying to figure out why. It's not the root filesystem, I downloaded slackware and it took a day to install and then running the aboriginal build under it (to reproduce the uClibc++ issue) has been running since yesterday and just made it base the simple-cross-compiler gcc build and into the kernel headers install... It reeeeally shouldn't be this slow. When I upgraded qemu to 0.15.0 something went "boing", need to figure out what and why... (Or is it something to do with emulating the 3.0 kernel? Hmmm...) > it seems the bottleneck is the cpp work done on the qemu vm. > google has targeted this weakness in their "pump mode" addition to > distcc, but that is unfortunately written in *python*. Except that preprocessing the headers inside the VM means you're working in a context where there ARE only one set of headers and falling back to /usr/include if you can't find something _won't_ accidentally stumble across bad information you shouldn't be using. > it seems nobody, and especially not big corporations, cares about > portability any more. Big corporations never cared, it's up to us to care. They trail along once everybody else is already doing whatever it is. > apart from its syntax which is even harder to learn than perl, make is > not that bad imo... at least it is available on nearly all systems and > compiles without patches, and is relatively powerful. > once you copy/pasted together your first working makefile, you can reuse > that relatively well.... > of course i could imagine a better solution, but hey, most of the rest > is much worse ;) There's _always_ something worse, that's no excuse to put up with an existing bad thing... Rob 1318465136.0 From rob at landley.net Thu Oct 13 05:27:59 2011 From: rob at landley.net (Rob Landley) Date: Thu, 13 Oct 2011 00:27:59 -0500 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E95271A.9030604@barfooze.de> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> <4E8E7669.7040502@landley.net> <4E8FDD7C.9000607@barfooze.de> <4E90880A.8040104@landley.net> <4E95271A.9030604@barfooze.de> Message-ID: <4E9676DF.9050408@landley.net> On 10/12/2011 12:35 AM, John Spencer wrote: > On 10/08/2011 07:27 PM, Rob Landley wrote: >> I note that uClibc currently has no s390 support, but these days QEMU >> _does_. This means I can't support all the QEMU targets using uClibc >> unless their development community gets fundamentally unstuck. >> >> If musl supported that target and uClibc didn't, I'd logically want to >> see about getting musl support into aboriginal itself. > as it looks currently, you'd have to make that port yourself ;) If I wanted to use musl, yes. I'll put it on the todo list somewhere after upgrading LFS to 6.8, getting funtoo-bootstrap to work, fixing chroot in the kernel and rewriting lxc, getting virtconsole to work, transitioning everything to device trees... > actually the arm port has just been finished and as it looks i'm > currently the only using/testing it... Did anybody build Linux From Scratch against i686 musl? > i'd expect mips/ppc support coming next, *if* some other ports will > happen in the near future. >> (This would mean >> at minimum building current busybox against it, plus an older GPLv2 >> release of a gnu toolchain (gcc 4.2.1, binutils-1.17, and make 3.81 were >> the last GPLv2 releases, and bash 2.05b is "good enough" about about 1/3 >> the size of modern bash.) > make 3.81 has the additional advantage that it builds older kernels as > well, since some breaking change has been introduced with make 3.82 (for > example linux 2.6.25 won't build on 3.82) Like Microsoft, the FSF believes you should never use stuff they didn't write. They give lip service to portability and backwards compatability but in reality? http://lwn.net/Articles/449524 When they break other people's stuff, they claim concern but actually _act_ happy. > the binutils however are too old to play nice with musl. I've got the binutils todo item, I hope to get to it this weekend. :) (You may have noticed, I sometimes need reminding. But right now: day job.) >> The rest of the packages used during the aboriginal linux build are >> distcc, e2fsprogs, genext2fs, and squashfs (which requires zlib). (And >> of course current linux but it doesn't depend on libc.) > is aufs enabled as well ? 1) I went to a union filesystem talk at OLS in 2006. I followed val henson's blog about union filesystem work for years. I've followed kernel threads about union filesystem stuff. I've seen something like five union filesystem implementations for Linux over the years, and when you said "aufs" I thought it was referring to the Andrew Filesystem. 2) I use /sbin/chroot-setup.sh and just cp most of it and bind mount other bits to get a writeable chroot. 3) Back before squashfs was merged I forward-ported it multiple times, taking various gentoo snapshots and such for each new kernel version. Then I stopped because out of tree patches are a huge amount of work to keep current and it breaks every single release. I'd love to have a union filesystem merged upstream, but I'm doing vanilla packages. If it's not in vanilla, it's out of scope for this project. :) > i thought about adding support for that to my > build manager, as it turned out that decompressing the kernel each time > i build it eats a lot of time (about 10 minutes in qemu). Decompressing the kernel on my _host_ laptop takes over a minute. It's kind of enormous. That's why I implemented the package cache: http://landley.net/aboriginal/FAQ.html#debug_source http://landley.net/aboriginal/FAQ.html#debug_package_cache http://landley.net/aboriginal/FAQ.html#debug_working_copies Conceptually you can gloss over all that as "extract and patch tarball, bulid it, then rm -rf when you're done", but using the package cache is way the heck faster than that for repeated builds. (Both of which are why I put up with the complexity of doing it.) > doing the > untaring in a separate step and overlay it with a build-only directory > would allow simply trashing the built stuff and restart clean without > having to untar again (since "make clean" won't remove patches, and so on). Um, yes. That's the package cache. (cp -l is a marvelous thing. The config entry SNAPSHOT_SYMLINK can do symlinks though, and explains why you might want to. Yes, I tried it both way and wound up making it configurable. The build control images use symlinks because they're crossing filesystems, since /mnt is bind mounted from the squashfs but /home is generally ext3.) >>>> (In aboriginal, all the information about a specific target is in the >>>> sources/targets files, one per target. At one point many moons ago i >>>> had documentation about adding a new target. um... >>>> http://landley.net/aboriginal/documentation.html#new_target I think. >>>> Wow that's out of date...) >> I need at least a month to do nothing but documentation, but I know from >> experience it wouldn't be enough. >> > > the aboriginal infrastructure is indeed pretty sweet and i was thinking > about wether i should adopt parts of it. > especially the automatic distcc configuration, although the > preprocessing power needed for some stuff makes it nearly useless in > those cases. if that bottleneck could be removed, it would even make > sense to allow to add more distcc-servers. Actually I think the current bottleneck is that the network's only dong 300k/second even with a gigabit interface. (10baseT is 1100ksecond, 100baseT is 11,000k/second. That's RIDICULOUSLY slow, and it didn't _used_ to be, trying to figure out what regressed. Possibly linux 3.0 issue fighting with the emulator? Need to track it down...) Also, tinycc's preprocessor is faster than gcc's, and the one in my fork at least was fairly compatible... > well, maybe some day a sane person (which happens to know python) will > come and port the distcc pump stuff to C, or just rewrite it from scratch. One of the great things about distcc is that coverting C99 .c into an elf .o is fairly resistant to version skew. All the stuff that has to match _up_ version-wise is in the headersand the libraries, all of which are handled on a single central node that has just one copy of everything. Distributing the preprocessing reintroduces the possibility of version skew. It requires each distcc node to have compatible headers _and_ to get the header search paths correct on a system that has more than one set of headers installed. I.E. it's inherently less reliable for what we're doing. One problem that does need to be fixed is that distcc doesn't always distribute compiles (compile and link on the same line, for example, or turning more than one .c file into a combined .o file), and it doesn't tell you when it DOESN'T distribute so it's hard to figure out whether or not it's working. I.E. writing my own tiny distcc (extending ccwrap.c to do this, basically) is on my todo list. Probably requires my own daemon. I looked into it but it's not a half-hour job... >> You're aware of uClibc++, right? (My project builds it and all. :) >> It's a bit stalled right now, but I have Garret's phone number around >> here somewhere... >> >> What's needed _in_ the libc? Stack unwinding cruft? >> >> > > from what i've heard there's special atexit/dynlink stuff needed and > partially some symbol names clash. > currently there's some discussion about that on the musl mailinglist. Ah right, global class instance constructors and destructors. I forgot about those. They implemented a horrible name mangling thing requiring them to break the linker _and_ gdb, and they couldn't avoid conflicting with existing symbol names? That's just sad. >>>>> i was told that it is faster and takes way less ram than gnu ld. >>>>> (which is not very surprising, given the quality of average gnu code) >>>> The tinycc linker is also buckets faster and less memory intensive than >>>> gnu ld. >>> how about this one ? http://code.google.com/p/ucpp/ > actually that is a *preprocessor*... we were talking about ripping out > the tcc preprocessor somewhere else... tinycc is a self-contained all in one compiler. It's got a preprocessor, a compiler, an assembler, and a linker, all in one binary. (It still needs stuff like objdump.) >> I expect gcc's days are numbered but displacing it is like displacing >> windows: it's an entrenched standard zealously defended by egocentric >> bastards out to impose Their Way upon the world, so there's work to do >> getting rid of it: >> >> http://flyingbynight.wordpress.com/2011/02/28/phnglui-mglw-nafh-cthuhu-riv-wgah-nagl-fhtag/ >> > i was looking lately at the tendra compiler, which has just been > uploaded to https://bitbucket.org/asmodai/tendra/ > that seems like a well designed compiler with good optimization potential. I went through a dozen open-sourceish compilers once. Most were incomplete and kind of crap. I vaguely recall that one, don't remember what was wrong with it, this was a few years back... > it uses some internal intermediate format (which is even standardized), > which then gets optimized according to the target. > however the build system is pretty outdated and i was unable to > bootstrap it in its current state. > i hope some activity on that project will start soon... I vaguely remember watcom got open sourced as abandonware a while ago. Having code with no community isn't very useful. >>>> Too bad the maintainer of that project is a windows developer, >>>> if it would just DIE I'd restart my fork but I refuse to fight zombies >>>> without a cricket bat. >>> hmm iirc the mob branch is the only active. it's not even that bad, i >>> checked it out lately and it built stuff which tcc 0.9.25 refused to build. >> My tree also built a lot of stuff 0.9.25 refused to build. That was >> sort of the point of my tree. > really unfortunate that you stopped it. but i have read your statement > and respect your reasons. > in the meantime, an uncoordinated "mob" drives the project on repo.or.cz ;) And you understand why that's a bad thing, right? >>> actually it is so broken that it defeats the purpose of the FSF, in that >>> it makes it too hard to change and recompile your free software, making >>> it unfree that way. >> The FSF has been self defeating for many years. If you want a RANT: >> >> http://landley.net/notes-2010.html#17-07-2010 >> http://landley.net/notes-2010.html#19-07-2010 >> >> (First part is background necessary to understand the second part. I >> keep meaning to write a book on computer history, but I have too many >> other things to do...) >> > > the mail from rms about "making the code hard to use" to get evil > companies out is indeed shocking. > it seems GNU software sucks by design. Yup. He's been shouted down from that position more recently, but the damage is done and he doesn't really change his mind, he just changes his tactics sometimes. >>>> You have to add said flag to the preprocessor as well, it sets a bunch >>>> of symbols telling you about your current target. Go: >>>> >>>> gcc -E -dM -< /dev/null | less >>>> >>>> Now do that for each of the cross compilers and diff the result. :) >>> ... thats quite a list. >> Now ponder that list and go "hey, it tells me my current target and my >> current endianness... what is half of ./configure for, anyway?" > > indeed. Not to mention #include and... Sigh. >> Add in >> "what is libtool for", or the fact that pkg-config is so obviously >> stupid you can sum it up with stick figures http://xkcd.com/927/ >> (because rpm and dpkg and portage and pacman and bitbake and so on >> weren't _enough_), and PKG_CONFIG=/bin/true is a beautiful thing... >> > > PKG_CONFIG=/bin/true <- that actually works ? Sometimes. (It returns success and says that whatever it is was NOT installed. If your build is ok with that, great. If not, maybe PKG_CONFIG="echo" or something might work, I haven't tried it.) Half of cross compiling is working out exactly how to lie to ./configure _this_ time around. >>>> You've learned never to install Libtool on Linux, right? >>> most stuff actually seems to come with its own libtool. >>> however i just found out that you have to delete *.la and magically >>> stuff builds, that failed earlier. >> Once upon a time I meant to do a libtool-stub that actually WOULD be a >> NOP successfully, like http://penma.de/code/gettext-stub/ and my little >> trick here: >> >> http://landley.net/hg/control-images/file/9/common/bootstrap/build-one-package.sh >> (lines 31-41). > > "Autoconf is useless" ;) You've got to do the vogon voice, though. >> Anyway: I need to make a NOP libtool that I can symlink the others to, >> which just converts the command line arguments to ld format and does >> NOTHING ELSE. A small shell script, probably. Then ln -sf as needed. > > i shall appreciate it as well. You see how my todo list gets insane? >>>> Um, send me a link again? >>> http://lists.busybox.net/pipermail/busybox/2011-July/076293.html >> Ah yes. I'll try to get to it this weekend. > > thanks for the patch. will test it as soon as the kernel compile is > finished... That _really_ shouldn't take that long. I'm poking at it... (This is the armv6l target? I built the whole of linux from scratch on that overnight...) Rob 1318483679.0 From rob at landley.net Fri Oct 14 15:58:46 2011 From: rob at landley.net (Rob Landley) Date: Fri, 14 Oct 2011 10:58:46 -0500 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E960125.6080706@barfooze.de> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> <4E8E7669.7040502@landley.net> <4E8FDD7C.9000607@barfooze.de> <4E90880A.8040104@landley.net> <4E95271A.9030604@barfooze.de> <4E960125.6080706@barfooze.de> Message-ID: <4E985C36.3090903@landley.net> On 10/12/2011 04:05 PM, John Spencer wrote: > On 10/12/2011 07:35 AM, John Spencer wrote: >> >> >> the aboriginal infrastructure is indeed pretty sweet and i was >> thinking about wether i should adopt parts of it. >> especially the automatic distcc configuration, although the >> preprocessing power needed for some stuff makes it nearly useless in >> those cases. if that bottleneck could be removed, it would even make >> sense to allow to add more distcc-servers. >> well, maybe some day a sane person (which happens to know python) will >> come and port the distcc pump stuff to C, or just rewrite it from >> scratch. > > actually the problem was mktimeconst.c which looped forever due to a bug > (1L vs 1LL)... i have taken the patch (linux-noperl-timeconst.patch) > from another source which wasn't fixed yet... builds in about 30 minutes > now. > I fixed that bug months ago: changeset: 1379:ddbd48ced0d7 user: Rob Landley date: Thu Jun 16 07:41:10 2011 -0500 files: sources/patches/linux-noperl-timeconst.patch description: Fix from Geoffroy Weisenhorn: on 32-bit hosts mktimeconst needs 1L<<31 to be an _unsigned_ long constant. But I made it unsigned instead of long long because 64 bit math on a 32 bit host is unpleasant. Who else is using it? (Just curious. I wrote that patch from scratch, and despite repeatedly posting it to linux-kernel nobody ever seemed to care but me...) Rob 1318607926.0 From maillist-aboriginal at barfooze.de Fri Oct 14 16:41:04 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Fri, 14 Oct 2011 18:41:04 +0200 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E985C36.3090903@landley.net> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> <4E8E7669.7040502@landley.net> <4E8FDD7C.9000607@barfooze.de> <4E90880A.8040104@landley.net> <4E95271A.9030604@barfooze.de> <4E960125.6080706@barfooze.de> <4E985C36.3090903@landley.net> Message-ID: <4E986620.2040406@barfooze.de> On 10/14/2011 05:58 PM, Rob Landley wrote: > On 10/12/2011 04:05 PM, John Spencer wrote: >> On 10/12/2011 07:35 AM, John Spencer wrote: >>> >>> the aboriginal infrastructure is indeed pretty sweet and i was >>> thinking about wether i should adopt parts of it. >>> especially the automatic distcc configuration, although the >>> preprocessing power needed for some stuff makes it nearly useless in >>> those cases. if that bottleneck could be removed, it would even make >>> sense to allow to add more distcc-servers. >>> well, maybe some day a sane person (which happens to know python) will >>> come and port the distcc pump stuff to C, or just rewrite it from >>> scratch. >> actually the problem was mktimeconst.c which looped forever due to a bug >> (1L vs 1LL)... i have taken the patch (linux-noperl-timeconst.patch) >> from another source which wasn't fixed yet... builds in about 30 minutes >> now. >> > I fixed that bug months ago: > > changeset: 1379:ddbd48ced0d7 > user: Rob Landley > date: Thu Jun 16 07:41:10 2011 -0500 > files: sources/patches/linux-noperl-timeconst.patch > description: > Fix from Geoffroy Weisenhorn: on 32-bit hosts mktimeconst needs > 1L<<31 to be an _unsigned_ long constant. > > But I made it unsigned instead of long long because 64 bit math on a 32 > bit host is unpleasant. although it doesn't matter for the 20 times the loop is executed ;) > Who else is using it? (Just curious. I wrote that patch from scratch, > and despite repeatedly posting it to linux-kernel nobody ever seemed to > care but me...) > i got it from the other musl "distro", https://github.com/pikhq/bootstrap-linux > Rob > 1318610464.0 From onefang at gmail.com Sat Oct 15 08:47:41 2011 From: onefang at gmail.com (David Seikel) Date: Sat, 15 Oct 2011 18:47:41 +1000 Subject: [Aboriginal] 1.1.0 problem creating an ext2 image. Message-ID: <20111015184741.28ac1f18@U64-desktop> In aboriginal 1.1.0 root-image.sh uses $IMAGE in the part of the script that is creating an ext2 disk image if one is requested. Problem is, that's not defined anywhere. So it ends up trying to dd to a directory, which dd complains about. Comparing with an older version, looks like the use of that variable was replaced by a hard coded name of hda.ext2 in the genext2fs command, but the rest of the script was not changed to suit. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rob at landley.net Sat Oct 15 22:48:22 2011 From: rob at landley.net (Rob Landley) Date: Sat, 15 Oct 2011 17:48:22 -0500 Subject: [Aboriginal] 1.1.0 problem creating an ext2 image. In-Reply-To: <20111015184741.28ac1f18@U64-desktop> References: <20111015184741.28ac1f18@U64-desktop> Message-ID: <4E9A0DB6.4000604@landley.net> On 10/15/2011 03:47 AM, David Seikel wrote: > In aboriginal 1.1.0 root-image.sh uses $IMAGE in the part of the script > that is creating an ext2 disk image if one is requested. Problem is, > that's not defined anywhere. So it ends up trying to dd to a > directory, which dd complains about. Ah. That variable is defined in system-image.sh, looks like I screwed it up when I broke out the root filesystem image generation from the system image assembly. Hmmm... There a debug echo right above it. Looks like I got distracted and wound up checking in half-finished code I hadn't tested. Oops? I was pretty sure I'd tested that. (The downside of supporting multiple image formats, gotta run parts of the build three times to test that. And in fact, this only only triggers if you select ext2 filesystem type AND set SYSIMAGE_HDA_MEGS to tell it to reserve extra space, so actually I have to test _four_ times. (I tested ext2 image generation, but the resizing logic was unfinished.) Yeah, the dd line actually is more debug code that shouldn't exist... Lemme fix this up, sorry about that. Rob P.S. The reason this is almost never used today is that the squashfs can be easily copied into a writeable chroot via the /sbin/chroot-setup script. This means that you can run dev-environment.sh multiple times to do different things, even in parallel, without your root filesystem changing and potentially needing a fsck or having some subtle behavior change. If you want to install more stuff in it you can do so in the chroot, but you always _start_ with a known system. That's how all the control-images stuff works. That said, if it's going to offer writeable ext2 root filesystems of any size, they should _work_. Fixing it now. Thanks for the heads up... 1318718902.0 From rob at landley.net Sun Oct 16 04:52:40 2011 From: rob at landley.net (Rob Landley) Date: Sat, 15 Oct 2011 23:52:40 -0500 Subject: [Aboriginal] Build error In-Reply-To: References: <4E8E245C.9050505@landley.net> <4E908AD2.6020004@landley.net> Message-ID: <4E9A6318.60705@landley.net> On 10/09/2011 08:30 AM, prasanna balan wrote: > On Sat, Oct 8, 2011 at 11:09 PM, Rob Landley wrote: >> On 10/06/2011 11:49 PM, prasanna balan wrote: >>> >>> On 7 Oct 2011 03:27, "Rob Landley" >> > wrote: >>>> >>>> On 10/06/2011 09:18 AM, prasanna balan wrote: >>>>> I tried building aboriginal 1.1.0 and it broke during uClibc++ native >>>>> compiler...The last few lines of the build are as below: >>>> >>>> You just ran ./build.sh i686? >>>> >>> >>> Forgot to mention. It was. /build.sh i686 >> >> That's why the build outputs stuff like: >> >>>>> === ccwrap (i686 native-compiler) >> >> Identifying what it's currently doing. Part of the question was "did >> you run stages individually", "did you change lots of config" knobs, >> "did you skip host-tools.sh"... the usual. Your answer implies "no" to >> all that. >> >>> I tried with NO_CPLUSPLUS =1 and it built without break means some issue >>> with uclibc++ exists. >>> I use 32 bit slackware current with ext4 fs on /home >> >> I downloaded the slackware DVD and the kernel kept panicing when booted >> from the DVD under virtualbox on my work machine. I'm trying again on >> my netbook but it's a longish download... It took a long time to download, install, and run the build on my netbook, but it went a lot faster when I transferred the image off my little netbook and onto the server upstairs. I did a default install from the dvd, wget the most recent release of the source, extracted it, did "./build.sh i686". It built to completion. I need more information to reproduce this problem. What filesystem are you using on /home? >> Rob >> > > I tried it again and it broke again with the same errors (that's > obvious)..This time I ran more/record-commands.sh and redid the build. > Details are as below: > > =================================================== > $ cat build/logs/cmdlines.i686.native-compiler.uClibc++ > make "defconfig" > gcc "-Os" "-S" "-o" "/dev/null" "-xc" "/dev/null" > gcc "-print-libgcc-file-name" > cut "-c1" > gcc "-dumpversion" > grep "-q" "as-needed" > ld "--help" > cut "-c1" > gcc "-dumpversion" > make "-C" "extra/config" "conf" > $ Um, that's odd. It should show you the commands "make" is running. (Did the build reset the $PATH somehow?) That... Oh. Hang on, Do this: export -p | grep PATH= Is your $PATH exported? If it's just a local variable, that could explain what you're seeing. (And I can fix that in sources/include.sh actually, I just haven't hit this particular environmental weirdness before. Well, not in this context, anyway.) > ================================================== > This specifically means that the recursive make breaks due to some > unknown reason.Hope this helps in debugging. It means that recursive make stops logging, which implies that the $PATH is no longer pointing to the logging wrapper directory. Except that include/functions.sh is exporting the PATH when it modifies it while setting the architecture. Hmmm... Can you run make with -d maybe? Rob 1318740760.0 From maillist-aboriginal at barfooze.de Sun Oct 16 17:16:46 2011 From: maillist-aboriginal at barfooze.de (John Spencer) Date: Sun, 16 Oct 2011 19:16:46 +0200 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E9676DF.9050408@landley.net> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> <4E8E7669.7040502@landley.net> <4E8FDD7C.9000607@barfooze.de> <4E90880A.8040104@landley.net> <4E95271A.9030604@barfooze.de> <4E9676DF.9050408@landley.net> Message-ID: <4E9B117E.60602@barfooze.de> On 10/13/2011 07:27 AM, Rob Landley wrote: > > Did anybody build Linux From Scratch against i686 musl? the bootstrap-linux i linked in my previous mail should be about the same > > I'd love to have a union filesystem merged upstream, but I'm doing > vanilla packages. If it's not in vanilla, it's out of scope for this > project. :) indeed, aufs has to be built as a separate package. >> i thought about adding support for that to my >> build manager, as it turned out that decompressing the kernel each time >> i build it eats a lot of time (about 10 minutes in qemu). > Decompressing the kernel on my _host_ laptop takes over a minute. It's > kind of enormous. That's why I implemented the package cache: > > http://landley.net/aboriginal/FAQ.html#debug_source > http://landley.net/aboriginal/FAQ.html#debug_package_cache > http://landley.net/aboriginal/FAQ.html#debug_working_copies > > Conceptually you can gloss over all that as "extract and patch tarball, > bulid it, then rm -rf when you're done", but using the package cache is > way the heck faster than that for repeated builds. (Both of which are > why I put up with the complexity of doing it.) >> doing the >> untaring in a separate step and overlay it with a build-only directory >> would allow simply trashing the built stuff and restart clean without >> having to untar again (since "make clean" won't remove patches, and so on). > Um, yes. That's the package cache. (cp -l is a marvelous thing. The > config entry SNAPSHOT_SYMLINK can do symlinks though, and explains why > you might want to. Yes, I tried it both way and wound up making it > configurable. The build control images use symlinks because they're > crossing filesystems, since /mnt is bind mounted from the squashfs but > /home is generally ext3.) > good idea. however it doesn't solve the patch issue. i'd prefer to be able to go back to the vanilla source code ... > Actually I think the current bottleneck is that the network's only dong > 300k/second even with a gigabit interface. (10baseT is 1100ksecond, > 100baseT is 11,000k/second. That's RIDICULOUSLY slow, and it didn't > _used_ to be, trying to figure out what regressed. indeed. > Possibly linux 3.0 > issue fighting with the emulator? Need to track it down...) from what i've read that's the issue with the kind of network support that aboriginal uses. there's another method which involves some iptable rules which apparently should be much faster and even allows icmp. > Also, tinycc's preprocessor is faster than gcc's, and the one in my fork > at least was fairly compatible... > >> well, maybe some day a sane person (which happens to know python) will >> come and port the distcc pump stuff to C, or just rewrite it from scratch. > One of the great things about distcc is that coverting C99 .c into an > elf .o is fairly resistant to version skew. All the stuff that has to > match _up_ version-wise is in the headersand the libraries, all of which > are handled on a single central node that has just one copy of everything. > > Distributing the preprocessing reintroduces the possibility of version > skew. It requires each distcc node to have compatible headers _and_ to > get the header search paths correct on a system that has more than one > set of headers installed. I.E. it's inherently less reliable for what > we're doing. > the "pump" stuff is supposed to send the headers from the host to the distcc server... > One problem that does need to be fixed is that distcc doesn't always > distribute compiles (compile and link on the same line, for example, or > turning more than one .c file into a combined .o file), and it doesn't > tell you when it DOESN'T distribute so it's hard to figure out whether > or not it's working. indeed. > I.E. writing my own tiny distcc (extending ccwrap.c to do this, > basically) is on my todo list. Probably requires my own daemon. I > looked into it but it's not a half-hour job... > >>> You're aware of uClibc++, right? (My project builds it and all. :) >>> It's a bit stalled right now, but I have Garret's phone number around >>> here somewhere... >>> >>> What's needed _in_ the libc? Stack unwinding cruft? >>> >>> >> from what i've heard there's special atexit/dynlink stuff needed and >> partially some symbol names clash. >> currently there's some discussion about that on the musl mailinglist. > Ah right, global class instance constructors and destructors. I forgot > about those. > > They implemented a horrible name mangling thing requiring them to break > the linker _and_ gdb, and they couldn't avoid conflicting with existing > symbol names? > > That's just sad. > i think it's just wchar_t being a keyword in C++ or somesuch. (at least with the clang libstdc++ thing). from what i've heard, the gnu impl. additionally makes assumptions about mangled names from types such as pthread_t, so if those are differently implemented, they get another mangled name inside C++ declarations which use the type. don't beat me to it, i'm no C++ expert at all and haven't looked into the issue myself. >>>>>> i was told that it is faster and takes way less ram than gnu ld. >>>>>> (which is not very surprising, given the quality of average gnu code) >>>>> The tinycc linker is also buckets faster and less memory intensive than >>>>> gnu ld. >>>> how about this one ? http://code.google.com/p/ucpp/ >> actually that is a *preprocessor*... we were talking about ripping out >> the tcc preprocessor somewhere else... > tinycc is a self-contained all in one compiler. It's got a > preprocessor, a compiler, an assembler, and a linker, all in one binary. > (It still needs stuff like objdump.) doesn't its one-pass compilation disallow any serious optimization ? apart from that, i'd really like a tcc which would support most targets and a full C99 spec. >>> I expect gcc's days are numbered but displacing it is like displacing >>> windows: it's an entrenched standard zealously defended by egocentric >>> bastards out to impose Their Way upon the world, so there's work to do >>> getting rid of it: >>> >>> http://flyingbynight.wordpress.com/2011/02/28/phnglui-mglw-nafh-cthuhu-riv-wgah-nagl-fhtag/ >>> >> i was looking lately at the tendra compiler, which has just been >> uploaded to https://bitbucket.org/asmodai/tendra/ >> that seems like a well designed compiler with good optimization potential. > I went through a dozen open-sourceish compilers once. Most were > incomplete and kind of crap. I vaguely recall that one, don't remember > what was wrong with it, this was a few years back... not much. it even has codegens for the most important platforms, i think ARM is the only one missing. it even supports 68020+. but the build system is kinda broken. once that's repaired, it'd be a hot candidate. ah yes, it seems to lack some C99 features as well. from all the compilers (written in C) i looked at, imo this it the one with the biggest potential and least amount of work involved to get it to replace gcc. >> it uses some internal intermediate format (which is even standardized), >> which then gets optimized according to the target. >> however the build system is pretty outdated and i was unable to >> bootstrap it in its current state. >> i hope some activity on that project will start soon... > I vaguely remember watcom got open sourced as abandonware a while ago. > Having code with no community isn't very useful. > for some reason i can't remember, i haven't considered watcom as a serious candidate. >>>>> Too bad the maintainer of that project is a windows developer, >>>>> if it would just DIE I'd restart my fork but I refuse to fight zombies >>>>> without a cricket bat. >>>> hmm iirc the mob branch is the only active. it's not even that bad, i >>>> checked it out lately and it built stuff which tcc 0.9.25 refused to build. >>> My tree also built a lot of stuff 0.9.25 refused to build. That was >>> sort of the point of my tree. >> really unfortunate that you stopped it. but i have read your statement >> and respect your reasons. >> in the meantime, an uncoordinated "mob" drives the project on repo.or.cz ;) > And you understand why that's a bad thing, right? > it's not a bad thing per se, but a clear strategy and some management wouldn't hurt. >>>> actually it is so broken that it defeats the purpose of the FSF, in that >>>> it makes it too hard to change and recompile your free software, making >>>> it unfree that way. >>> The FSF has been self defeating for many years. If you want a RANT: >>> >>> http://landley.net/notes-2010.html#17-07-2010 >>> http://landley.net/notes-2010.html#19-07-2010 >>> >>> (First part is background necessary to understand the second part. I >>> keep meaning to write a book on computer history, but I have too many >>> other things to do...) >>> >> the mail from rms about "making the code hard to use" to get evil >> companies out is indeed shocking. >> it seems GNU software sucks by design. > Yup. He's been shouted down from that position more recently, but the > damage is done and he doesn't really change his mind, he just changes > his tactics sometimes. > >>>>> You have to add said flag to the preprocessor as well, it sets a bunch >>>>> of symbols telling you about your current target. Go: >>>>> >>>>> gcc -E -dM -< /dev/null | less >>>>> >>>>> Now do that for each of the cross compilers and diff the result. :) >>>> ... thats quite a list. >>> Now ponder that list and go "hey, it tells me my current target and my >>> current endianness... what is half of ./configure for, anyway?" >> indeed. > Not to mention #include and... > > Sigh. autoconf is an archaic, broken idea, which is obsoleted with standards such as C99. if your system doesn't comply to that, make your vendor support it or use another system. it's not the job of the software supplier to have a backup for every libc function/type. how many hours in my life have been wasted in the fight against this broken crap ? if it was at least readable and not thousands of line long, with broken indentation all over. it should just die. >>> Add in >>> "what is libtool for", or the fact that pkg-config is so obviously >>> stupid you can sum it up with stick figures http://xkcd.com/927/ >>> (because rpm and dpkg and portage and pacman and bitbake and so on >>> weren't _enough_), and PKG_CONFIG=/bin/true is a beautiful thing... >>> >> PKG_CONFIG=/bin/true<- that actually works ? > Sometimes. (It returns success and says that whatever it is was NOT > installed. If your build is ok with that, great. If not, maybe > PKG_CONFIG="echo" or something might work, I haven't tried it.) mhmm. another idiotic system one has to learn to find out how to circumvent it. > Half of cross compiling is working out exactly how to lie to ./configure > _this_ time around. > indeed. *sigh* >>>>> You've learned never to install Libtool on Linux, right? >>>> most stuff actually seems to come with its own libtool. >>>> however i just found out that you have to delete *.la and magically >>>> stuff builds, that failed earlier. >>> Once upon a time I meant to do a libtool-stub that actually WOULD be a >>> NOP successfully, like http://penma.de/code/gettext-stub/ and my little >>> trick here: >>> >>> http://landley.net/hg/control-images/file/9/common/bootstrap/build-one-package.sh >>> (lines 31-41). >> "Autoconf is useless" ;) > You've got to do the vogon voice, though. let's just do it the vogon way and shoot it into space. >>> Anyway: I need to make a NOP libtool that I can symlink the others to, >>> which just converts the command line arguments to ld format and does >>> NOTHING ELSE. A small shell script, probably. Then ln -sf as needed. >> i shall appreciate it as well. > You see how my todo list gets insane? well, at least that one should be possible to finish at a free afternoon, if you know what it should do. >>>>> Um, send me a link again? >>>> http://lists.busybox.net/pipermail/busybox/2011-July/076293.html >>> Ah yes. I'll try to get to it this weekend. >> thanks for the patch. will test it as soon as the kernel compile is >> finished... > That _really_ shouldn't take that long. I'm poking at it... (This is > the armv6l target? I built the whole of linux from scratch on that > overnight...) it was the ever looping mktimeconst and me being to lazy to check if the build was hanging or just slow. > Rob > 1318785406.0 From onefang at gmail.com Sun Oct 16 21:05:31 2011 From: onefang at gmail.com (David Seikel) Date: Mon, 17 Oct 2011 07:05:31 +1000 Subject: [Aboriginal] Regression in tarball naming? Message-ID: <20111017070531.48f44f91@U64-desktop> I just ended up with a "lfs-bootstrap.tar.gz-i486" file after running the lfs-bootstrap to test out the latest versions of things. I thought we sorted that issue out before? -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rob at landley.net Mon Oct 17 12:02:34 2011 From: rob at landley.net (Rob Landley) Date: Mon, 17 Oct 2011 07:02:34 -0500 Subject: [Aboriginal] What's musl, anyway? In-Reply-To: <4E9B117E.60602@barfooze.de> References: <4E8B6D58.5030103@landley.net> <4E8CDFC8.7060708@gmx.net> <4E8E2538.10004@landley.net> <4E8E37BF.3070304@barfooze.de> <4E8E7669.7040502@landley.net> <4E8FDD7C.9000607@barfooze.de> <4E90880A.8040104@landley.net> <4E95271A.9030604@barfooze.de> <4E9676DF.9050408@landley.net> <4E9B117E.60602@barfooze.de> Message-ID: <4E9C195A.1050907@landley.net> On 10/16/2011 12:16 PM, John Spencer wrote: > On 10/13/2011 07:27 AM, Rob Landley wrote: >> >> Did anybody build Linux From Scratch against i686 musl? > > the bootstrap-linux i linked in my previous mail should be about the same Heh. Not even close. My basic Aboriginal Linux build creates the smallest and simplest Linux system capable of rebuilding itself entirely from source code. I.E. I can boot into this sucker (on real hardware or under QEMU) and re-run the build in there, and get a usable out of it. It sets up the minimal amount of infrastructure required to self-host. (The only optional bit is distcc, and I could trim down the busybox .config to a smaller subset instead of "defconfig" but that actually _adds_ complexity to the build so I stopped doing it.) The fact the resulting root filesystem is capable of rebuilding itself from soruce under itself _implies_ that it should be powerful enough to build any other software and installing it natively... but whether or not that's actually _true_ involves corner cases of the C library, compiler, and the linker that that core set of packages don't necessarily exercise. (For example, dynamic linking isn't strictly required for a self-bootstrapping system but you haven't been able to build X11 without it since sometime during the clinton administration. Dynamic linking isn't picky about link order and doesn't mind duplicate symbols, static linking is and does.) Linux From Scratch 6.7, chapter 6 (building the new system), is over 4 dozen GNU packages. I automated the Linux From Scratch build using the aboriginal linux "build control image" infrastructure, and built a new chroot dir out of those 4 dozen packages using the toolchain and C library in aboriginal linux. See: http://landley.net/aboriginal/control-images The lfs-bootstrap.hdc build control image natively builds all those packages, in order, under the aboriginal linux root filesystem. It configures them, makes them, and installs them. (By default it gradually replaces the busybox commands a few at a time, but you can also have it install its stuff in the $PATH after busybox, so the new commands don't get used if there's already a busybox version.) This is essentially driving sheep across a minefield: if something is wrong with the build environment (compiler, C library, or command line tools) then one or more of the packages will break. I've actually built a little under 90 packages using this technique (Linux From Scratch and then a chunk of beyond Linux From Scratch, getting X11 infrastructure and a bunch of clients up, remotely attaching to an external X server to play xchess and run xeyes and have an xterm and so on, part of a demo showing that the qualcomm hexagon port of linux worked reasonably well and was worth further funding. Alas, that was behind the scenes at qualcomm and I had to reimplement it after I left. I've redone the LFS build, but not the BLFS stuff yet.) The fact that musl can give me a shell prompt does not mean: A) you can natively rebuild under that environment to be self-hosting. B) you can port something like knoppix to musl. >> I'd love to have a union filesystem merged upstream, but I'm doing >> vanilla packages. If it's not in vanilla, it's out of scope for this >> project. :) > > indeed, aufs has to be built as a separate package. Then I'm not blocking you. :) >>> i thought about adding support for that to my >>> build manager, as it turned out that decompressing the kernel each time >>> i build it eats a lot of time (about 10 minutes in qemu). >> Decompressing the kernel on my _host_ laptop takes over a minute. It's >> kind of enormous. That's why I implemented the package cache: >> >> http://landley.net/aboriginal/FAQ.html#debug_source >> http://landley.net/aboriginal/FAQ.html#debug_package_cache >> http://landley.net/aboriginal/FAQ.html#debug_working_copies >> >> Conceptually you can gloss over all that as "extract and patch tarball, >> bulid it, then rm -rf when you're done", but using the package cache is >> way the heck faster than that for repeated builds. (Both of which are >> why I put up with the complexity of doing it.) > >>> doing the >>> untaring in a separate step and overlay it with a build-only directory >>> would allow simply trashing the built stuff and restart clean without >>> having to untar again (since "make clean" won't remove patches, and >>> so on). >> Um, yes. That's the package cache. (cp -l is a marvelous thing. The >> config entry SNAPSHOT_SYMLINK can do symlinks though, and explains why >> you might want to. Yes, I tried it both way and wound up making it >> configurable. The build control images use symlinks because they're >> crossing filesystems, since /mnt is bind mounted from the squashfs but >> /home is generally ext3.) >> > > good idea. however it doesn't solve the patch issue. > i'd prefer to be able to go back to the vanilla source code ... Um, which patch issue? The sources/patches directory contains patches. Those patches are applied to the extracted tarballs. Each time the build needs to create a snapshot of the package cache, it checks the md5sum of each component (the tarball and each patch) against the md5sums stored in the "sha1-for-source.txt" file in the extracted master copy of the source. If that set of md5sums cancel out, it does the "cp -l" trick to set up a new snapshot and life goes on. If the set of md5sums does NOT cancel out (patch added, removed, or changed, or the tarball's different), it does an rm -rf on the old source directory and then re-extracts and re-patches it, then does the snapshot. (Note, the sha1sum is appended ot the file _after_ the tarball successfully extracts or the patch successfully applies, meaning if there's a glitch at that level it'll automatically retry next time because the set of sha1sums won't match up.) (Note, you can edit the FILES in the package cache all you want for debug purposes, it just checks the upstream ingredients it made the directory from, not any hand hacking you've done since then. Then rm -rf the directory when you're done and it'll re-create it. I cover that in the above FAQ stuff.) >> Actually I think the current bottleneck is that the network's only dong >> 300k/second even with a gigabit interface. (10baseT is 1100ksecond, >> 100baseT is 11,000k/second. That's RIDICULOUSLY slow, and it didn't >> _used_ to be, trying to figure out what regressed. > indeed. >> Possibly linux 3.0 >> issue fighting with the emulator? Need to track it down...) > from what i've read that's the issue with the kind of network support > that aboriginal uses. Um, you mean "-net user"? I don't think so, I've gotten that to do over a megabyte per second before... > there's another method which involves some iptable rules which > apparently should be much faster and even allows icmp. And which requires root access on the host, which my project does not. >> Distributing the preprocessing reintroduces the possibility of version >> skew. It requires each distcc node to have compatible headers _and_ to >> get the header search paths correct on a system that has more than one >> set of headers installed. I.E. it's inherently less reliable for what >> we're doing. >> > > the "pump" stuff is supposed to send the headers from the host to the > distcc server... Given the utter horror of gcc's path logic, how the hell does it FIND them? A glitch I need to fix right now is that CPUS is not being set right when distcc is set up. It's supposed to do CPUS=3 and it's doing CPUS=1, and that doesn't overlap preprocessing and host network access/compilation. (You need at least CPUS=2 and in my testing CPUS=3 was a sweet spot, although it was a while ago and I need to retest...) >> They implemented a horrible name mangling thing requiring them to break >> the linker _and_ gdb, and they couldn't avoid conflicting with existing >> symbol names? >> >> That's just sad. >> > i think it's just wchar_t being a keyword in C++ or somesuch. (at least > with the clang libstdc++ thing). > from what i've heard, the gnu impl. additionally makes assumptions about > mangled names from types such as pthread_t, so if those are differently > implemented, they get another mangled name inside C++ declarations which > use the type. > don't beat me to it, i'm no C++ expert at all and haven't looked into > the issue myself. I was a C++ expert around 1993, then the added templates to the language and I went "that's just peverted" and went back to C. I've had to debug some deep weirdness since then, and every time I come away with fresh scars and a deeper conviction that it's an utterly horrible language that KEEPS MANAGING TO GET WORSE. They have to invent new ways to suck, and they _do_... >>>>>>> i was told that it is faster and takes way less ram than gnu ld. >>>>>>> (which is not very surprising, given the quality of average gnu >>>>>>> code) >>>>>> The tinycc linker is also buckets faster and less memory intensive >>>>>> than >>>>>> gnu ld. >>>>> how about this one ? http://code.google.com/p/ucpp/ >>> actually that is a *preprocessor*... we were talking about ripping out >>> the tcc preprocessor somewhere else... >> tinycc is a self-contained all in one compiler. It's got a >> preprocessor, a compiler, an assembler, and a linker, all in one binary. >> (It still needs stuff like objdump.) > > doesn't its one-pass compilation disallow any serious optimization ? Yup. But you can still do basic dead code elimination, constant propogation, expression simplification, and so on. And keep in mind tinycc has been used to build gcc: http://www.dwheeler.com/trusting-trust/ Once you've got a self-hosting native environment, you can install additional packages to arbitrarily complicate it. The important bit is to solve the bootstrapping problem SEPERATELY, and then make adding additional features natively a self-contained thing that doesn't have magic cross compiling dependencies sticking to it. > apart from that, i'd really like a tcc which would support most targets > and a full C99 spec. It's pretty close, it's just grisckha hijacked it back to come up with an "official" version that's a windows toy, and I didn't feel like fighting the owner of the tinycc.org domain. When that project dies, I may regain interest. Until then, they can go however many years between releases they like. >>>> I expect gcc's days are numbered but displacing it is like displacing >>>> windows: it's an entrenched standard zealously defended by egocentric >>>> bastards out to impose Their Way upon the world, so there's work to do >>>> getting rid of it: >>>> >>>> http://flyingbynight.wordpress.com/2011/02/28/phnglui-mglw-nafh-cthuhu-riv-wgah-nagl-fhtag/ >>>> >>>> >>> i was looking lately at the tendra compiler, which has just been >>> uploaded to https://bitbucket.org/asmodai/tendra/ >>> that seems like a well designed compiler with good optimization >>> potential. >> I went through a dozen open-sourceish compilers once. Most were >> incomplete and kind of crap. I vaguely recall that one, don't remember >> what was wrong with it, this was a few years back... > not much. it even has codegens for the most important platforms, i think > ARM is the only one missing. I consulted Wikipedia's opinion, which said: > In August 2003 TenDRA split into two projects, TenDRA.org and > Ten15.org. Both projects petered out around 2006?2007. And they link to archive.org for information about the compiler. That puts it pretty much in the same boat as openwatcom. > it even supports 68020+. > but the build system is kinda broken. once that's repaired, it'd be a > hot candidate. Repaired by whom? (Are you doing it?) Does it have a repository, a mailing list, and releases? > ah yes, it seems to lack some C99 features as well. > from all the compilers (written in C) i looked at, imo this it the one > with the biggest potential and least amount of work involved to get it > to replace gcc. Who is doing that work? When I made that assessment for myself (circa 2006) I saw tinycc as having the shortest path to gcc replacement, and I dug in, and all I managed to do was revive the old zombie project and be overshadowed by it. I'd shake other developers out of the woodwork doing things like upgrading windows support and they ALWAYS did it against the version on tinycc.org, not my version. The last straw was x86-64 support, a big batch of fresh development (which I was only about 1/3 of the way through doing myself), which was a patch against the CVS version, not against mine. That was my "throw in the towel" moment. All my effort was just making people take up the OLD project, minus all my cleanups. And years later they're going "we should be able to specify the header search paths at build time" and I go "I did that in 2008, see here", and it turns into yet another flamewar: http://lists.nongnu.org/archive/html/tinycc-devel/2011-10/msg00000.html And the hilarious parts is that the months where it DOESN'T have a flamewar look like this: http://lists.nongnu.org/archive/html/tinycc-devel/2011-06/threads.html (And I see that since I gave grischka the last word he hasn't posted to the list for 2 weeks. He's the project's "maintainer". You wonder why I gave up on it?) Anyway, after that experience I'm not particularly looking to get back into compiler development just now. I'll test a project that has momentum but I'm not playing Sysiphus with somebody else's ball, when I fully expect them to take that ball and go home if I get it rolling. (Yeah, I know, mixing metaphors with an eggbeater...) >>> it uses some internal intermediate format (which is even standardized), >>> which then gets optimized according to the target. >>> however the build system is pretty outdated and i was unable to >>> bootstrap it in its current state. >>> i hope some activity on that project will start soon... >> I vaguely remember watcom got open sourced as abandonware a while ago. >> Having code with no community isn't very useful. > > for some reason i can't remember, i haven't considered watcom as a > serious candidate. Again, no development community. It was abandonware, code with no developers. It was not a live project, it was a snapshot in time of something nobody worked on anymore. It wasn't a small and simple thing you can read through in an afternoon, but there's nobody to ask questions about its design anymore, and if you do make your own changes where do you submit them? Will it ever have another release? Or do you just maintain your own forked version on top of everything else you have to do? I did a survey on open source compilers a few years ago. Since then, open64.net has shown more life than I expected (its most recent release was April), and pcc has shown less. >>>>>> Too bad the maintainer of that project is a windows developer, >>>>>> if it would just DIE I'd restart my fork but I refuse to fight >>>>>> zombies >>>>>> without a cricket bat. >>>>> hmm iirc the mob branch is the only active. it's not even that bad, i >>>>> checked it out lately and it built stuff which tcc 0.9.25 refused >>>>> to build. >>>> My tree also built a lot of stuff 0.9.25 refused to build. That was >>>> sort of the point of my tree. >>> really unfortunate that you stopped it. but i have read your statement >>> and respect your reasons. >>> in the meantime, an uncoordinated "mob" drives the project on >>> repo.or.cz ;) >> And you understand why that's a bad thing, right? >> > > it's not a bad thing per se, but a clear strategy and some management > wouldn't hurt. Open source is a publishing project, just like a magazine. In a magazine, you have a slush pile which demonstrates Sturgeon's Law: 90% of it is crap, submitted by freelancers hoping to be published. An editor goes through the slush pile and cherry picks the best few submissions, cleans them up and stitches them together, and puts out the next issue. This pattern repeats itself all over the place. The internet is primarily porn, cat pictures, and emo blogs: google searches show you the top ten hits out of the hundreds of thousands containing the words youw ant. Link aggregators like slashdot and fark and such fight off sturgeon's law by taking in thousands of submissions of possibly interesting links and publishing the top dozen or two each day. Linux distros like Koppix put out a CD with around 600 packages out of the tens of thousands on sourceforge. With a real editor, a hand-written rejection letter is a GOOD thing because it means your submission showed potential, and the editor is encouraging you to retry, sometimes with guidance about what needs to be fixed to make it acceptable to them. If Linus Torvalds replies to your patch and tells you to make changes, it's ENCOURAGEMENT even if he's ripping it a new one, because you GOT HIS ATTENTION. A mob branch publishes the raw slush pile, with no editorial control, no architectural oversight, no direction, no design guidance, no saying "that's not within the scope of this project" before Zawinski's Law kicks in and the thing's suddenly a chat service with its own email like World of Warcraft. If nobody is in charge, the old parable about "too many cooks" explains what happens. Sure, maintainers only really have veto power over a volunteer developer community, but that's a lot if used intelligently. When Alan Cox says "a maintainer's job is to say no", this is what he's talking about. >>>>>> You have to add said flag to the preprocessor as well, it sets a >>>>>> bunch >>>>>> of symbols telling you about your current target. Go: >>>>>> >>>>>> gcc -E -dM -< /dev/null | less >>>>>> >>>>>> Now do that for each of the cross compilers and diff the result. :) >>>>> ... thats quite a list. >>>> Now ponder that list and go "hey, it tells me my current target and my >>>> current endianness... what is half of ./configure for, anyway?" >>> indeed. >> Not to mention #include and... >> >> Sigh. > > autoconf is an archaic, broken idea, which is obsoleted with standards > such as C99. Chunks of it were obsoleted by standards such as LP64. (I linked to that from the end of http://landley.net/code/toybox/design.html which is a general rant about software design from back when I felt like swimming upstream against the busybox development community.) > if your system doesn't comply to that, make your vendor support it or > use another system. > it's not the job of the software supplier to have a backup for every > libc function/type. Yup. And yet I even have to argue the busybox guys out of this sometimes. Sigh. The Linux Weekly News guys call this "the platform problem": http://lwn.net/Articles/443531/ > how many hours in my life have been wasted in the fight against this > broken crap ? > if it was at least readable and not thousands of line long, with broken > indentation all over. > > it should just die. I take a more active "Kill it with fire" approach, but convincing projects not to use it is hard. (Dropbear didn't used to use it, and then started. That was a sad day. Several people suggested busybox use it during my tenure: my response was not polite.) >>>> Add in >>>> "what is libtool for", or the fact that pkg-config is so obviously >>>> stupid you can sum it up with stick figures http://xkcd.com/927/ >>>> (because rpm and dpkg and portage and pacman and bitbake and so on >>>> weren't _enough_), and PKG_CONFIG=/bin/true is a beautiful thing... >>>> >>> PKG_CONFIG=/bin/true<- that actually works ? >> Sometimes. (It returns success and says that whatever it is was NOT >> installed. If your build is ok with that, great. If not, maybe >> PKG_CONFIG="echo" or something might work, I haven't tried it.) > > mhmm. another idiotic system one has to learn to find out how to > circumvent it. At least it's not HAL. >> Half of cross compiling is working out exactly how to lie to ./configure >> _this_ time around. >> > indeed. *sigh* Hence the "We cross compile so you don't have to" motto in the title bar. Getting to the point where you can natively compile under emulation means you don't have to cross compile any more after that point, because cross compiling sucks. (Using distcc does _not_ re-open the cross compiling can of worms; I wouldn't do it if it did.) >>>> Anyway: I need to make a NOP libtool that I can symlink the others to, >>>> which just converts the command line arguments to ld format and does >>>> NOTHING ELSE. A small shell script, probably. Then ln -sf as needed. >>> i shall appreciate it as well. >> You see how my todo list gets insane? > > well, at least that one should be possible to finish at a free > afternoon, if you know what it should do. I happily accept patches. :) >>>>>> Um, send me a link again? >>>>> http://lists.busybox.net/pipermail/busybox/2011-July/076293.html >>>> Ah yes. I'll try to get to it this weekend. >>> thanks for the patch. will test it as soon as the kernel compile is >>> finished... Did it work, by the way? Rob 1318852954.0 From rob at landley.net Mon Oct 17 13:16:44 2011 From: rob at landley.net (Rob Landley) Date: Mon, 17 Oct 2011 08:16:44 -0500 Subject: [Aboriginal] Regression in tarball naming? In-Reply-To: <20111017070531.48f44f91@U64-desktop> References: <20111017070531.48f44f91@U64-desktop> Message-ID: <4E9C2ABC.6010702@landley.net> On 10/16/2011 04:05 PM, David Seikel wrote: > I just ended up with a "lfs-bootstrap.tar.gz-i486" file after running > the lfs-bootstrap to test out the latest versions of things. I thought > we sorted that issue out before? Not a regression, I believe it's always done that. I blogged about it last month, but didn't actually address it: http://landley.net/notes-2011.html#17-09-2011 As I said, "This is a design conflict between the control image being target agnostic and the host system needing to distinguish between files uploaded into the same directory." The thing is, if I rename the tarball then I should really rename the directory the tarball extracts to so they match, which means either the build has to use the $HOST name in setup-chroot or I need to rename the directory before tarring it up. Not a huge deal, but just icky enough I haven't done it yet, since the problem it fixes is also minor. The upload function sends it with a host-specific name, nothing else in the native build cares about that at the moment. Rob 1318857404.0 From rob at landley.net Wed Oct 19 02:44:00 2011 From: rob at landley.net (Rob Landley) Date: Tue, 18 Oct 2011 21:44:00 -0500 Subject: [Aboriginal] Fun with powerpc, and USE_UNSTABLE is now USE_ALT Message-ID: <4E9E3970.2010108@landley.net> The powerpc system call interface changed recently: commit 86250b9d12caa1a3dee12a7cf638b7dd70eaadb6 Author: Ian Munsie Date: Wed Aug 25 18:50:28 2010 +0000 powerpc: Wire up direct socket system calls This patch wires up the various socket system calls on PowerPC so that userspace can call them directly, rather than by going through the multiplexed socketcall system call. Signed-off-by: Ian Munsie Signed-off-by: Benjamin Herrenschmidt Which means that dropbear and some of the network stuff in busybox use that new system call when built against kernel headers with that commit (2.6.36 and newer, I think), and if you try to run those binaries on older kernels you get "unsupported syscall" error. (I noticed this with dropbear server mode.) It's easy enough to build against an older kernel version, for a definition of "easy" that works around kernel.org not having archival versions back up yet: cd ~/linux/linux git archive v2.6.35 --prefix=linux/ | bzip2 > \ ~/aboriginal/aboriginal/packages/alt-linux-0.tar.bz2 And then yanking everything but alt-linux-pmacorder.patch from sources/patches because the perl removal patches keep breakig every other release. (I really want to get that upstream...) I did a blog entry about this, and added a FAQ entry, and it also pointed out that the sources and patches are all prefixed with "alt-" but the control variables (in config and download.sh) are UNSTABLE, and that's inconsistent naming, and since there's nothing unstable about building with an _old_ version of the kernel I made it USE_ALT in config and ALT= in ./download.sh and then fixed up the rest of the plumbing. (Not checked in yet, testing...) Anyway, that's why there's currently a dropbearmulti-powerpc-old binary in extras. :) Poking at the 3.1-rc10 kernel too, while I'm there... Rob 1318992240.0 From prazzb at gmail.com Mon Oct 24 16:49:53 2011 From: prazzb at gmail.com (prasanna balan) Date: Mon, 24 Oct 2011 22:19:53 +0530 Subject: [Aboriginal] Build error In-Reply-To: <4E9A6318.60705@landley.net> References: <4E8E245C.9050505@landley.net> <4E908AD2.6020004@landley.net> <4E9A6318.60705@landley.net> Message-ID: On Sun, Oct 16, 2011 at 10:22 AM, Rob Landley wrote: > On 10/09/2011 08:30 AM, prasanna balan wrote: >> On Sat, Oct 8, 2011 at 11:09 PM, Rob Landley wrote: >>> On 10/06/2011 11:49 PM, prasanna balan wrote: >>>> >>>> On 7 Oct 2011 03:27, "Rob Landley" >>> > wrote: >>>>> >>>>> On 10/06/2011 09:18 AM, prasanna balan wrote: >>>>>> I tried building aboriginal 1.1.0 and it broke during uClibc++ native >>>>>> compiler...The last few lines of the build are as below: >>>>> >>>>> You just ran ./build.sh i686? >>>>> >>>> >>>> Forgot to mention. It was. /build.sh i686 >>> >>> That's why the build outputs stuff like: >>> >>>>>> === ccwrap (i686 native-compiler) >>> >>> Identifying what it's currently doing. ?Part of the question was "did >>> you run stages individually", "did you change lots of config" knobs, >>> "did you skip host-tools.sh"... ?the usual. ?Your answer implies "no" to >>> all that. >>> >>>> I tried with NO_CPLUSPLUS =1 and it built without break means some issue >>>> with uclibc++ exists. >>>> I use 32 bit slackware current with ext4 fs on /home >>> >>> I downloaded the slackware DVD and the kernel kept panicing when booted >>> from the DVD under virtualbox on my work machine. ?I'm trying again on >>> my netbook but it's a longish download... > > It took a long time to download, install, and run the build on my > netbook, but it went a lot faster when I transferred the image off my > little netbook and onto the server upstairs. > > I did a default install from the dvd, wget the most recent release of > the source, extracted it, did "./build.sh i686". ?It built to completion. Don't know why, still a NO on my laptop...only the uClibc++ package... > I need more information to reproduce this problem. ?What filesystem are > you using on /home? > $mount /dev/root on / type ext4 (rw,relatime,barrier=1,data=ordered) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) tmpfs on /dev/shm type tmpfs (rw) $ No different /home.....in the same partition >>> Rob >>> >> >> I tried it again and it broke again with the same errors (that's >> obvious)..This time I ran more/record-commands.sh and redid the build. >> Details are as below: >> >> =================================================== >> $ cat build/logs/cmdlines.i686.native-compiler.uClibc++ >> make "defconfig" >> gcc "-Os" "-S" "-o" "/dev/null" "-xc" "/dev/null" >> gcc "-print-libgcc-file-name" >> cut "-c1" >> gcc "-dumpversion" >> grep "-q" "as-needed" >> ld "--help" >> cut "-c1" >> gcc "-dumpversion" >> make "-C" "extra/config" "conf" >> $ > > Um, that's odd. ?It should show you the commands "make" is running. > (Did the build reset the $PATH somehow?) ?That... > > Oh. ?Hang on, ?Do this: > > ?export -p | grep PATH= > > Is your $PATH exported? If it's just a local variable, that could > explain what you're seeing. ?(And I can fix that in sources/include.sh > actually, I just haven't hit this particular environmental weirdness > before. ?Well, not in this context, anyway.) > Didn't understand what u meant above but the above command is showing my old $PATH and not the one that aboriginal replaces using function sanitize_environment >> ================================================== >> This specifically means that the recursive make breaks due to some >> unknown reason.Hope this helps in debugging. > > It means that recursive make stops logging, which implies that the $PATH > is no longer pointing to the logging wrapper directory. > > Except that include/functions.sh is exporting the PATH when it modifies > it while setting the architecture. ?Hmmm... > > Can you run make with -d maybe? I re-did make with make-d at uClibc++.build....Basically shows the same thing as above...The file is about 900 lines long....Attaching the file...if it may help > Rob > prazzb -------------- next part -------------- fi make[1]: Leaving directory `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/build-gcc/gcc' cleanup build-gcc cleanup gcc-core === ccwrap (i686 native-compiler) ]2;i686 native-compiler ccwrap=== uClibc++ (i686 native-compiler) ]2;i686 native-compiler uClibc++Snapshot 'uClibc++'... GNU Make 3.82 Built for i486-slackware-linux-gnu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Reading makefiles... Reading makefile `Makefile'... Reading makefile `Rules.mak' (search path) (no ~ expansion)... Updating makefiles.... Considering target file `Rules.mak'. Looking for an implicit rule for `Rules.mak'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.o'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.c'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.cc'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.C'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.cpp'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.p'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.f'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.F'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.m'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.r'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.s'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.S'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.mod'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.sh'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak,v'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `RCS/Rules.mak,v'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `RCS/Rules.mak'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `s.Rules.mak'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `SCCS/s.Rules.mak'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.o'. Looking for a rule with intermediate file `Rules.mak.o'. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.c'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.cc'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.C'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.cpp'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.p'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.f'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.F'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.m'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.r'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.s'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.S'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.mod'. Trying pattern rule with stem `Rules.mak.o'. Trying implicit prerequisite `Rules.mak.o,v'. Trying pattern rule with stem `Rules.mak.o'. Trying implicit prerequisite `RCS/Rules.mak.o,v'. Trying pattern rule with stem `Rules.mak.o'. Trying implicit prerequisite `RCS/Rules.mak.o'. Trying pattern rule with stem `Rules.mak.o'. Trying implicit prerequisite `s.Rules.mak.o'. Trying pattern rule with stem `Rules.mak.o'. Trying implicit prerequisite `SCCS/s.Rules.mak.o'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.c'. Looking for a rule with intermediate file `Rules.mak.c'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.y'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.l'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.w'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.w'. Trying pattern rule with stem `Rules.mak.c'. Trying implicit prerequisite `Rules.mak.c,v'. Trying pattern rule with stem `Rules.mak.c'. Trying implicit prerequisite `RCS/Rules.mak.c,v'. Trying pattern rule with stem `Rules.mak.c'. Trying implicit prerequisite `RCS/Rules.mak.c'. Trying pattern rule with stem `Rules.mak.c'. Trying implicit prerequisite `s.Rules.mak.c'. Trying pattern rule with stem `Rules.mak.c'. Trying implicit prerequisite `SCCS/s.Rules.mak.c'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.y'. Looking for a rule with intermediate file `Rules.mak.y'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.y'. Trying implicit prerequisite `Rules.mak.y,v'. Trying pattern rule with stem `Rules.mak.y'. Trying implicit prerequisite `RCS/Rules.mak.y,v'. Trying pattern rule with stem `Rules.mak.y'. Trying implicit prerequisite `RCS/Rules.mak.y'. Trying pattern rule with stem `Rules.mak.y'. Trying implicit prerequisite `s.Rules.mak.y'. Trying pattern rule with stem `Rules.mak.y'. Trying implicit prerequisite `SCCS/s.Rules.mak.y'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.l'. Looking for a rule with intermediate file `Rules.mak.l'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.l'. Trying implicit prerequisite `Rules.mak.l,v'. Trying pattern rule with stem `Rules.mak.l'. Trying implicit prerequisite `RCS/Rules.mak.l,v'. Trying pattern rule with stem `Rules.mak.l'. Trying implicit prerequisite `RCS/Rules.mak.l'. Trying pattern rule with stem `Rules.mak.l'. Trying implicit prerequisite `s.Rules.mak.l'. Trying pattern rule with stem `Rules.mak.l'. Trying implicit prerequisite `SCCS/s.Rules.mak.l'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.w'. Looking for a rule with intermediate file `Rules.mak.w'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.w'. Trying implicit prerequisite `Rules.mak.w,v'. Trying pattern rule with stem `Rules.mak.w'. Trying implicit prerequisite `RCS/Rules.mak.w,v'. Trying pattern rule with stem `Rules.mak.w'. Trying implicit prerequisite `RCS/Rules.mak.w'. Trying pattern rule with stem `Rules.mak.w'. Trying implicit prerequisite `s.Rules.mak.w'. Trying pattern rule with stem `Rules.mak.w'. Trying implicit prerequisite `SCCS/s.Rules.mak.w'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.w'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.cc'. Looking for a rule with intermediate file `Rules.mak.cc'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.cc'. Trying implicit prerequisite `Rules.mak.cc,v'. Trying pattern rule with stem `Rules.mak.cc'. Trying implicit prerequisite `RCS/Rules.mak.cc,v'. Trying pattern rule with stem `Rules.mak.cc'. Trying implicit prerequisite `RCS/Rules.mak.cc'. Trying pattern rule with stem `Rules.mak.cc'. Trying implicit prerequisite `s.Rules.mak.cc'. Trying pattern rule with stem `Rules.mak.cc'. Trying implicit prerequisite `SCCS/s.Rules.mak.cc'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.C'. Looking for a rule with intermediate file `Rules.mak.C'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.C'. Trying implicit prerequisite `Rules.mak.C,v'. Trying pattern rule with stem `Rules.mak.C'. Trying implicit prerequisite `RCS/Rules.mak.C,v'. Trying pattern rule with stem `Rules.mak.C'. Trying implicit prerequisite `RCS/Rules.mak.C'. Trying pattern rule with stem `Rules.mak.C'. Trying implicit prerequisite `s.Rules.mak.C'. Trying pattern rule with stem `Rules.mak.C'. Trying implicit prerequisite `SCCS/s.Rules.mak.C'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.cpp'. Looking for a rule with intermediate file `Rules.mak.cpp'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.cpp'. Trying implicit prerequisite `Rules.mak.cpp,v'. Trying pattern rule with stem `Rules.mak.cpp'. Trying implicit prerequisite `RCS/Rules.mak.cpp,v'. Trying pattern rule with stem `Rules.mak.cpp'. Trying implicit prerequisite `RCS/Rules.mak.cpp'. Trying pattern rule with stem `Rules.mak.cpp'. Trying implicit prerequisite `s.Rules.mak.cpp'. Trying pattern rule with stem `Rules.mak.cpp'. Trying implicit prerequisite `SCCS/s.Rules.mak.cpp'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.p'. Looking for a rule with intermediate file `Rules.mak.p'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.web'. Trying pattern rule with stem `Rules.mak.p'. Trying implicit prerequisite `Rules.mak.p,v'. Trying pattern rule with stem `Rules.mak.p'. Trying implicit prerequisite `RCS/Rules.mak.p,v'. Trying pattern rule with stem `Rules.mak.p'. Trying implicit prerequisite `RCS/Rules.mak.p'. Trying pattern rule with stem `Rules.mak.p'. Trying implicit prerequisite `s.Rules.mak.p'. Trying pattern rule with stem `Rules.mak.p'. Trying implicit prerequisite `SCCS/s.Rules.mak.p'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.web'. Looking for a rule with intermediate file `Rules.mak.web'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.web'. Trying implicit prerequisite `Rules.mak.web,v'. Trying pattern rule with stem `Rules.mak.web'. Trying implicit prerequisite `RCS/Rules.mak.web,v'. Trying pattern rule with stem `Rules.mak.web'. Trying implicit prerequisite `RCS/Rules.mak.web'. Trying pattern rule with stem `Rules.mak.web'. Trying implicit prerequisite `s.Rules.mak.web'. Trying pattern rule with stem `Rules.mak.web'. Trying implicit prerequisite `SCCS/s.Rules.mak.web'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.f'. Looking for a rule with intermediate file `Rules.mak.f'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.F'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.r'. Trying pattern rule with stem `Rules.mak.f'. Trying implicit prerequisite `Rules.mak.f,v'. Trying pattern rule with stem `Rules.mak.f'. Trying implicit prerequisite `RCS/Rules.mak.f,v'. Trying pattern rule with stem `Rules.mak.f'. Trying implicit prerequisite `RCS/Rules.mak.f'. Trying pattern rule with stem `Rules.mak.f'. Trying implicit prerequisite `s.Rules.mak.f'. Trying pattern rule with stem `Rules.mak.f'. Trying implicit prerequisite `SCCS/s.Rules.mak.f'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.F'. Looking for a rule with intermediate file `Rules.mak.F'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.F'. Trying implicit prerequisite `Rules.mak.F,v'. Trying pattern rule with stem `Rules.mak.F'. Trying implicit prerequisite `RCS/Rules.mak.F,v'. Trying pattern rule with stem `Rules.mak.F'. Trying implicit prerequisite `RCS/Rules.mak.F'. Trying pattern rule with stem `Rules.mak.F'. Trying implicit prerequisite `s.Rules.mak.F'. Trying pattern rule with stem `Rules.mak.F'. Trying implicit prerequisite `SCCS/s.Rules.mak.F'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.r'. Looking for a rule with intermediate file `Rules.mak.r'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.l'. Trying pattern rule with stem `Rules.mak.r'. Trying implicit prerequisite `Rules.mak.r,v'. Trying pattern rule with stem `Rules.mak.r'. Trying implicit prerequisite `RCS/Rules.mak.r,v'. Trying pattern rule with stem `Rules.mak.r'. Trying implicit prerequisite `RCS/Rules.mak.r'. Trying pattern rule with stem `Rules.mak.r'. Trying implicit prerequisite `s.Rules.mak.r'. Trying pattern rule with stem `Rules.mak.r'. Trying implicit prerequisite `SCCS/s.Rules.mak.r'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.F'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.m'. Looking for a rule with intermediate file `Rules.mak.m'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.ym'. Trying pattern rule with stem `Rules.mak.m'. Trying implicit prerequisite `Rules.mak.m,v'. Trying pattern rule with stem `Rules.mak.m'. Trying implicit prerequisite `RCS/Rules.mak.m,v'. Trying pattern rule with stem `Rules.mak.m'. Trying implicit prerequisite `RCS/Rules.mak.m'. Trying pattern rule with stem `Rules.mak.m'. Trying implicit prerequisite `s.Rules.mak.m'. Trying pattern rule with stem `Rules.mak.m'. Trying implicit prerequisite `SCCS/s.Rules.mak.m'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.ym'. Looking for a rule with intermediate file `Rules.mak.ym'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.ym'. Trying implicit prerequisite `Rules.mak.ym,v'. Trying pattern rule with stem `Rules.mak.ym'. Trying implicit prerequisite `RCS/Rules.mak.ym,v'. Trying pattern rule with stem `Rules.mak.ym'. Trying implicit prerequisite `RCS/Rules.mak.ym'. Trying pattern rule with stem `Rules.mak.ym'. Trying implicit prerequisite `s.Rules.mak.ym'. Trying pattern rule with stem `Rules.mak.ym'. Trying implicit prerequisite `SCCS/s.Rules.mak.ym'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.r'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.s'. Looking for a rule with intermediate file `Rules.mak.s'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.S'. Trying pattern rule with stem `Rules.mak.s'. Trying implicit prerequisite `Rules.mak.s,v'. Trying pattern rule with stem `Rules.mak.s'. Trying implicit prerequisite `RCS/Rules.mak.s,v'. Trying pattern rule with stem `Rules.mak.s'. Trying implicit prerequisite `RCS/Rules.mak.s'. Trying pattern rule with stem `Rules.mak.s'. Trying implicit prerequisite `s.Rules.mak.s'. Trying pattern rule with stem `Rules.mak.s'. Trying implicit prerequisite `SCCS/s.Rules.mak.s'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.S'. Looking for a rule with intermediate file `Rules.mak.S'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.S'. Trying implicit prerequisite `Rules.mak.S,v'. Trying pattern rule with stem `Rules.mak.S'. Trying implicit prerequisite `RCS/Rules.mak.S,v'. Trying pattern rule with stem `Rules.mak.S'. Trying implicit prerequisite `RCS/Rules.mak.S'. Trying pattern rule with stem `Rules.mak.S'. Trying implicit prerequisite `s.Rules.mak.S'. Trying pattern rule with stem `Rules.mak.S'. Trying implicit prerequisite `SCCS/s.Rules.mak.S'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.S'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.mod'. Looking for a rule with intermediate file `Rules.mak.mod'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.mod'. Trying implicit prerequisite `Rules.mak.mod,v'. Trying pattern rule with stem `Rules.mak.mod'. Trying implicit prerequisite `RCS/Rules.mak.mod,v'. Trying pattern rule with stem `Rules.mak.mod'. Trying implicit prerequisite `RCS/Rules.mak.mod'. Trying pattern rule with stem `Rules.mak.mod'. Trying implicit prerequisite `s.Rules.mak.mod'. Trying pattern rule with stem `Rules.mak.mod'. Trying implicit prerequisite `SCCS/s.Rules.mak.mod'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.c'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.cc'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.C'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.cpp'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.p'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.f'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.F'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.m'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.r'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.s'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.S'. Trying pattern rule with stem `Rules.mak'. Rejecting impossible implicit prerequisite `Rules.mak.mod'. Trying pattern rule with stem `Rules.mak'. Trying implicit prerequisite `Rules.mak.sh'. Looking for a rule with intermediate file `Rules.mak.sh'. Avoiding implicit rule recursion. Trying pattern rule with stem `Rules.mak.sh'. Trying implicit prerequisite `Rules.mak.sh,v'. Trying pattern rule with stem `Rules.mak.sh'. Trying implicit prerequisite `RCS/Rules.mak.sh,v'. Trying pattern rule with stem `Rules.mak.sh'. Trying implicit prerequisite `RCS/Rules.mak.sh'. Trying pattern rule with stem `Rules.mak.sh'. Trying implicit prerequisite `s.Rules.mak.sh'. Trying pattern rule with stem `Rules.mak.sh'. Trying implicit prerequisite `SCCS/s.Rules.mak.sh'. No implicit rule found for `Rules.mak'. Finished prerequisites of target file `Rules.mak'. No need to remake target `Rules.mak'. Considering target file `Makefile'. Looking for an implicit rule for `Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.o'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.c'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.cc'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.C'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.cpp'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.p'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.f'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.F'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.m'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.r'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.s'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.S'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.mod'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.sh'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile,v'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `RCS/Makefile,v'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `RCS/Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `s.Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `SCCS/s.Makefile'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.o'. Looking for a rule with intermediate file `Makefile.o'. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.c'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.cc'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.C'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.cpp'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.p'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.f'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.F'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.m'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.r'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.s'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.S'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.mod'. Trying pattern rule with stem `Makefile.o'. Trying implicit prerequisite `Makefile.o,v'. Trying pattern rule with stem `Makefile.o'. Trying implicit prerequisite `RCS/Makefile.o,v'. Trying pattern rule with stem `Makefile.o'. Trying implicit prerequisite `RCS/Makefile.o'. Trying pattern rule with stem `Makefile.o'. Trying implicit prerequisite `s.Makefile.o'. Trying pattern rule with stem `Makefile.o'. Trying implicit prerequisite `SCCS/s.Makefile.o'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.c'. Looking for a rule with intermediate file `Makefile.c'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.y'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.l'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.w'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.w'. Trying pattern rule with stem `Makefile.c'. Trying implicit prerequisite `Makefile.c,v'. Trying pattern rule with stem `Makefile.c'. Trying implicit prerequisite `RCS/Makefile.c,v'. Trying pattern rule with stem `Makefile.c'. Trying implicit prerequisite `RCS/Makefile.c'. Trying pattern rule with stem `Makefile.c'. Trying implicit prerequisite `s.Makefile.c'. Trying pattern rule with stem `Makefile.c'. Trying implicit prerequisite `SCCS/s.Makefile.c'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.y'. Looking for a rule with intermediate file `Makefile.y'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.y'. Trying implicit prerequisite `Makefile.y,v'. Trying pattern rule with stem `Makefile.y'. Trying implicit prerequisite `RCS/Makefile.y,v'. Trying pattern rule with stem `Makefile.y'. Trying implicit prerequisite `RCS/Makefile.y'. Trying pattern rule with stem `Makefile.y'. Trying implicit prerequisite `s.Makefile.y'. Trying pattern rule with stem `Makefile.y'. Trying implicit prerequisite `SCCS/s.Makefile.y'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.l'. Looking for a rule with intermediate file `Makefile.l'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.l'. Trying implicit prerequisite `Makefile.l,v'. Trying pattern rule with stem `Makefile.l'. Trying implicit prerequisite `RCS/Makefile.l,v'. Trying pattern rule with stem `Makefile.l'. Trying implicit prerequisite `RCS/Makefile.l'. Trying pattern rule with stem `Makefile.l'. Trying implicit prerequisite `s.Makefile.l'. Trying pattern rule with stem `Makefile.l'. Trying implicit prerequisite `SCCS/s.Makefile.l'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.w'. Looking for a rule with intermediate file `Makefile.w'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.w'. Trying implicit prerequisite `Makefile.w,v'. Trying pattern rule with stem `Makefile.w'. Trying implicit prerequisite `RCS/Makefile.w,v'. Trying pattern rule with stem `Makefile.w'. Trying implicit prerequisite `RCS/Makefile.w'. Trying pattern rule with stem `Makefile.w'. Trying implicit prerequisite `s.Makefile.w'. Trying pattern rule with stem `Makefile.w'. Trying implicit prerequisite `SCCS/s.Makefile.w'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.w'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.cc'. Looking for a rule with intermediate file `Makefile.cc'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.cc'. Trying implicit prerequisite `Makefile.cc,v'. Trying pattern rule with stem `Makefile.cc'. Trying implicit prerequisite `RCS/Makefile.cc,v'. Trying pattern rule with stem `Makefile.cc'. Trying implicit prerequisite `RCS/Makefile.cc'. Trying pattern rule with stem `Makefile.cc'. Trying implicit prerequisite `s.Makefile.cc'. Trying pattern rule with stem `Makefile.cc'. Trying implicit prerequisite `SCCS/s.Makefile.cc'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.C'. Looking for a rule with intermediate file `Makefile.C'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.C'. Trying implicit prerequisite `Makefile.C,v'. Trying pattern rule with stem `Makefile.C'. Trying implicit prerequisite `RCS/Makefile.C,v'. Trying pattern rule with stem `Makefile.C'. Trying implicit prerequisite `RCS/Makefile.C'. Trying pattern rule with stem `Makefile.C'. Trying implicit prerequisite `s.Makefile.C'. Trying pattern rule with stem `Makefile.C'. Trying implicit prerequisite `SCCS/s.Makefile.C'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.cpp'. Looking for a rule with intermediate file `Makefile.cpp'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.cpp'. Trying implicit prerequisite `Makefile.cpp,v'. Trying pattern rule with stem `Makefile.cpp'. Trying implicit prerequisite `RCS/Makefile.cpp,v'. Trying pattern rule with stem `Makefile.cpp'. Trying implicit prerequisite `RCS/Makefile.cpp'. Trying pattern rule with stem `Makefile.cpp'. Trying implicit prerequisite `s.Makefile.cpp'. Trying pattern rule with stem `Makefile.cpp'. Trying implicit prerequisite `SCCS/s.Makefile.cpp'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.p'. Looking for a rule with intermediate file `Makefile.p'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.web'. Trying pattern rule with stem `Makefile.p'. Trying implicit prerequisite `Makefile.p,v'. Trying pattern rule with stem `Makefile.p'. Trying implicit prerequisite `RCS/Makefile.p,v'. Trying pattern rule with stem `Makefile.p'. Trying implicit prerequisite `RCS/Makefile.p'. Trying pattern rule with stem `Makefile.p'. Trying implicit prerequisite `s.Makefile.p'. Trying pattern rule with stem `Makefile.p'. Trying implicit prerequisite `SCCS/s.Makefile.p'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.web'. Looking for a rule with intermediate file `Makefile.web'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.web'. Trying implicit prerequisite `Makefile.web,v'. Trying pattern rule with stem `Makefile.web'. Trying implicit prerequisite `RCS/Makefile.web,v'. Trying pattern rule with stem `Makefile.web'. Trying implicit prerequisite `RCS/Makefile.web'. Trying pattern rule with stem `Makefile.web'. Trying implicit prerequisite `s.Makefile.web'. Trying pattern rule with stem `Makefile.web'. Trying implicit prerequisite `SCCS/s.Makefile.web'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.f'. Looking for a rule with intermediate file `Makefile.f'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.F'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.r'. Trying pattern rule with stem `Makefile.f'. Trying implicit prerequisite `Makefile.f,v'. Trying pattern rule with stem `Makefile.f'. Trying implicit prerequisite `RCS/Makefile.f,v'. Trying pattern rule with stem `Makefile.f'. Trying implicit prerequisite `RCS/Makefile.f'. Trying pattern rule with stem `Makefile.f'. Trying implicit prerequisite `s.Makefile.f'. Trying pattern rule with stem `Makefile.f'. Trying implicit prerequisite `SCCS/s.Makefile.f'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.F'. Looking for a rule with intermediate file `Makefile.F'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.F'. Trying implicit prerequisite `Makefile.F,v'. Trying pattern rule with stem `Makefile.F'. Trying implicit prerequisite `RCS/Makefile.F,v'. Trying pattern rule with stem `Makefile.F'. Trying implicit prerequisite `RCS/Makefile.F'. Trying pattern rule with stem `Makefile.F'. Trying implicit prerequisite `s.Makefile.F'. Trying pattern rule with stem `Makefile.F'. Trying implicit prerequisite `SCCS/s.Makefile.F'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.r'. Looking for a rule with intermediate file `Makefile.r'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.l'. Trying pattern rule with stem `Makefile.r'. Trying implicit prerequisite `Makefile.r,v'. Trying pattern rule with stem `Makefile.r'. Trying implicit prerequisite `RCS/Makefile.r,v'. Trying pattern rule with stem `Makefile.r'. Trying implicit prerequisite `RCS/Makefile.r'. Trying pattern rule with stem `Makefile.r'. Trying implicit prerequisite `s.Makefile.r'. Trying pattern rule with stem `Makefile.r'. Trying implicit prerequisite `SCCS/s.Makefile.r'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.F'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.m'. Looking for a rule with intermediate file `Makefile.m'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.ym'. Trying pattern rule with stem `Makefile.m'. Trying implicit prerequisite `Makefile.m,v'. Trying pattern rule with stem `Makefile.m'. Trying implicit prerequisite `RCS/Makefile.m,v'. Trying pattern rule with stem `Makefile.m'. Trying implicit prerequisite `RCS/Makefile.m'. Trying pattern rule with stem `Makefile.m'. Trying implicit prerequisite `s.Makefile.m'. Trying pattern rule with stem `Makefile.m'. Trying implicit prerequisite `SCCS/s.Makefile.m'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.ym'. Looking for a rule with intermediate file `Makefile.ym'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.ym'. Trying implicit prerequisite `Makefile.ym,v'. Trying pattern rule with stem `Makefile.ym'. Trying implicit prerequisite `RCS/Makefile.ym,v'. Trying pattern rule with stem `Makefile.ym'. Trying implicit prerequisite `RCS/Makefile.ym'. Trying pattern rule with stem `Makefile.ym'. Trying implicit prerequisite `s.Makefile.ym'. Trying pattern rule with stem `Makefile.ym'. Trying implicit prerequisite `SCCS/s.Makefile.ym'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.r'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.s'. Looking for a rule with intermediate file `Makefile.s'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.S'. Trying pattern rule with stem `Makefile.s'. Trying implicit prerequisite `Makefile.s,v'. Trying pattern rule with stem `Makefile.s'. Trying implicit prerequisite `RCS/Makefile.s,v'. Trying pattern rule with stem `Makefile.s'. Trying implicit prerequisite `RCS/Makefile.s'. Trying pattern rule with stem `Makefile.s'. Trying implicit prerequisite `s.Makefile.s'. Trying pattern rule with stem `Makefile.s'. Trying implicit prerequisite `SCCS/s.Makefile.s'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.S'. Looking for a rule with intermediate file `Makefile.S'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.S'. Trying implicit prerequisite `Makefile.S,v'. Trying pattern rule with stem `Makefile.S'. Trying implicit prerequisite `RCS/Makefile.S,v'. Trying pattern rule with stem `Makefile.S'. Trying implicit prerequisite `RCS/Makefile.S'. Trying pattern rule with stem `Makefile.S'. Trying implicit prerequisite `s.Makefile.S'. Trying pattern rule with stem `Makefile.S'. Trying implicit prerequisite `SCCS/s.Makefile.S'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.S'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.mod'. Looking for a rule with intermediate file `Makefile.mod'. Avoiding implicit rule recursion. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.mod'. Trying implicit prerequisite `Makefile.mod,v'. Trying pattern rule with stem `Makefile.mod'. Trying implicit prerequisite `RCS/Makefile.mod,v'. Trying pattern rule with stem `Makefile.mod'. Trying implicit prerequisite `RCS/Makefile.mod'. Trying pattern rule with stem `Makefile.mod'. Trying implicit prerequisite `s.Makefile.mod'. Trying pattern rule with stem `Makefile.mod'. Trying implicit prerequisite `SCCS/s.Makefile.mod'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.c'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.cc'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.C'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.cpp'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.p'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.f'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.F'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.m'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.r'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.s'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.S'. Trying pattern rule with stem `Makefile'. Rejecting impossible implicit prerequisite `Makefile.mod'. Trying pattern rule with stem `Makefile'. Trying implicit prerequisite `Makefile.sh'. Looking for a rule with intermediate file `Makefile.sh'. Avoiding implicit rule recursion. Trying pattern rule with stem `Makefile.sh'. Trying implicit prerequisite `Makefile.sh,v'. Trying pattern rule with stem `Makefile.sh'. Trying implicit prerequisite `RCS/Makefile.sh,v'. Trying pattern rule with stem `Makefile.sh'. Trying implicit prerequisite `RCS/Makefile.sh'. Trying pattern rule with stem `Makefile.sh'. Trying implicit prerequisite `s.Makefile.sh'. Trying pattern rule with stem `Makefile.sh'. Trying implicit prerequisite `SCCS/s.Makefile.sh'. No implicit rule found for `Makefile'. Finished prerequisites of target file `Makefile'. No need to remake target `Makefile'. Updating goal targets.... Considering target file `defconfig'. File `defconfig' does not exist. Considering target file `extra/config/conf'. File `extra/config/conf' does not exist. Finished prerequisites of target file `extra/config/conf'. Must remake target `extra/config/conf'. Invoking recipe from Makefile:46 to update target `extra/config/conf'. make -C extra/config conf Putting child 0x8085630 (extra/config/conf) PID 29754 on the chain. Live child 0x8085630 (extra/config/conf) PID 29754 GNU Make 3.82 Built for i486-slackware-linux-gnu Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Reading makefiles... Reading makefile `Makefile'... Reading makefile `../../Rules.mak' (search path) (no ~ expansion)... Reading makefile `../../.config' (search path) (don't care) (no ~ expansion)... make[1]: Entering directory `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config' make[1]: *** ../../.config: Is a directory. Stop. make[1]: Leaving directory `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config' Reaping losing child 0x8085630 PID 29754 make: *** [extra/config/conf] Error 2 Removing child 0x8085630 PID 29754 from chain. Exiting due to errors (i686 native-compiler uClibc++) real 28m41.932s user 23m25.724s sys 2m47.762s From rob at landley.net Thu Oct 27 04:29:34 2011 From: rob at landley.net (Rob Landley) Date: Wed, 26 Oct 2011 23:29:34 -0500 Subject: [Aboriginal] Build error In-Reply-To: References: <4E8E245C.9050505@landley.net> <4E908AD2.6020004@landley.net> <4E9A6318.60705@landley.net> Message-ID: <4EA8DE2E.7050304@landley.net> On 10/24/2011 11:49 AM, prasanna balan wrote: >> I did a default install from the dvd, wget the most recent release of >> the source, extracted it, did "./build.sh i686". It built to completion. > > Don't know why, still a NO on my laptop...only the uClibc++ package... What filesystem type are you using? (ext3? ext4? xfs?) >> I need more information to reproduce this problem. What filesystem are >> you using on /home? >> > > $mount > /dev/root on / type ext4 (rw,relatime,barrier=1,data=ordered) > proc on /proc type proc (rw) > sysfs on /sys type sysfs (rw) > tmpfs on /dev/shm type tmpfs (rw) > $ > > No different /home.....in the same partition Which means it's ext4. I tested against ext3. And my image isn't big enough. Looks like I need to re-download the iso and rerun the install with ext4. (32 bit version? Right...) >> Can you run make with -d maybe? > > I re-did make with make-d at uClibc++.build....Basically shows the > same thing as above...The file is about 900 lines long....Attaching > the file...if it may help Reading makefile `../../.config' (search path) (don't care) (no ~ expansion)... make[1]: Entering directory `/home/prazzb/Documents/Others/aboriginalTest/aboriginal/build/temp-i686/uClibc++/extra/config' make[1]: *** ../../.config: Is a directory. Stop. Yeah, that's not particularly helpful. This could be an ext4 bug. Interesting if so. The retest is likely to take a while, might not have results until the weekend, but I'm on it. Thanks, Rob 1319689774.0 From prazzb at gmail.com Thu Oct 27 11:30:36 2011 From: prazzb at gmail.com (prasanna balan) Date: Thu, 27 Oct 2011 17:00:36 +0530 Subject: [Aboriginal] linux-fixmips patch not required Message-ID: linux-fixmips patch is breaking the build. Turned out that the patch went into mainstream via changeset [1]. Remove the patch as it's no longer required. prazzb [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=852fe3105e94ca26d1b3df7e2cb6878ebdd67608 1319715036.0 From rob at landley.net Thu Oct 27 13:27:14 2011 From: rob at landley.net (Rob Landley) Date: Thu, 27 Oct 2011 08:27:14 -0500 Subject: [Aboriginal] linux-fixmips patch not required In-Reply-To: References: Message-ID: <4EA95C32.9010209@landley.net> On 10/27/2011 06:30 AM, prasanna balan wrote: > linux-fixmips patch is breaking the build. Turned out that the patch > went into mainstream via changeset [1]. > Remove the patch as it's no longer required. Ah, sorry. Deleted it locally here, which is why my tests passed, but forgot to commit the delete. (Alas, deleted files don't show up on an hg diff...) Thanks, Rob 1319722034.0 From rob at landley.net Mon Oct 31 01:01:21 2011 From: rob at landley.net (Rob Landley) Date: Sun, 30 Oct 2011 20:01:21 -0500 Subject: [Aboriginal] Getting ready for a release. Message-ID: <4EADF361.4070908@landley.net> Just a minor dot release, but the 3.1 kernel is out (in the repo, need to regression test the targets again), and I upgraded lfs-bootstrap to 6.8 (even though 7.0 just came out and I need to upgrade _again_, but oh well...) I've been spending a lot of time poking at funtoo recently. (This is Daniel Robbins' gentoo relaunch, ala xfree86->x.org and gcc->egcs.) Daniel wants me to do a funtoo-bootstrap based on the aboriginal root filesystem, and I'm working on it. Couple of bug fixes otherwise. Updated e2fsprogs. Nothing major... Rob 1320022881.0