From rob at landley.net Mon Oct 6 05:41:22 2014 From: rob at landley.net (Rob Landley) Date: Mon, 06 Oct 2014 00:41:22 -0500 Subject: [Aboriginal] Coming up on another release... Message-ID: <54322B82.3030404@landley.net> So, toybox 0.5.0 and linxu 3.17 are both out, and they're in the repo and building a test thing right now. Still haven't gotten the toolchain tweaked to fix the musl dynamic linking issue, but I hope to find some time for it this week. Also, I might want to make an external toolchain building project that does newer toolchains. I wouldn't distribute binaries of those (GPLv3 is a proprietary license I don't want to get on me) but buildroot deprecated and _removed_ its native toolchain code, and crosstool-ng apparently decided not to go there, and aboriginal needs BOTH cross and native toolchains to do its thing, so... I'd still love to see ellcc do this, but last time I poked at it the static binaries were leaking all sorts of host toolchain bits (their llvm binary was calling the _host_ ld out of the $PATH, it was just sad...) Quite possibly it's improved since. Dunno. I'd love if somebody else did this or me, but in the absence of somebody stepping up and doing it... Sigh. Rob 1412574082.0 From scsijon at lamiaworks.com.au Tue Oct 7 02:53:04 2014 From: scsijon at lamiaworks.com.au (scsijon) Date: Tue, 07 Oct 2014 13:53:04 +1100 Subject: [Aboriginal] toolchains In-Reply-To: References: Message-ID: <54335590.9030506@lamiaworks.com.au> > > Also, I might want to make an external toolchain building project that > does newer toolchains. I wouldn't distribute binaries of those (GPLv3 is > a proprietary license I don't want to get on me) but buildroot > deprecated and _removed_ its native toolchain code, and crosstool-ng > apparently decided not to go there, and aboriginal needs BOTH cross and > native toolchains to do its thing, so... might be worth having a quick look at how T2 does theirs in building T2 then, as they can go down 9 layers (although usually only 5 or 7 are needed) of toolchain to do both. 1412650384.0 From rob at landley.net Tue Oct 7 03:26:43 2014 From: rob at landley.net (Rob Landley) Date: Mon, 06 Oct 2014 22:26:43 -0500 Subject: [Aboriginal] toolchains In-Reply-To: <54335590.9030506@lamiaworks.com.au> References: <54335590.9030506@lamiaworks.com.au> Message-ID: <54335D73.4060704@landley.net> On 10/06/14 21:53, scsijon wrote: > >> >> Also, I might want to make an external toolchain building project that >> does newer toolchains. I wouldn't distribute binaries of those (GPLv3 is >> a proprietary license I don't want to get on me) but buildroot >> deprecated and _removed_ its native toolchain code, and crosstool-ng >> apparently decided not to go there, and aboriginal needs BOTH cross and >> native toolchains to do its thing, so... > > might be worth having a quick look at how T2 does theirs in building T2 > then, as they can go down 9 layers (although usually only 5 or 7 are > needed) of toolchain to do both. Back up: What's T2? What does "9 layers" mean in this context? (Linux From Scratch generally has basic instructions how to build currentish gcc, if I care enough I can just read their version.) Rob 1412652403.0 From alain.toussaint at securivm.ca Tue Oct 7 03:29:26 2014 From: alain.toussaint at securivm.ca (Alain Toussaint) Date: Mon, 6 Oct 2014 23:29:26 -0400 Subject: [Aboriginal] toolchains In-Reply-To: <54335D73.4060704@landley.net> References: <54335590.9030506@lamiaworks.com.au> <54335D73.4060704@landley.net> Message-ID: > What's T2? I admit I was curious too? Alain -------------- next part -------------- An HTML attachment was scrubbed... URL: From scsijon at lamiaworks.com.au Wed Oct 8 10:23:28 2014 From: scsijon at lamiaworks.com.au (scsijon) Date: Wed, 08 Oct 2014 21:23:28 +1100 Subject: [Aboriginal] Fwd: toolchains In-Reply-To: <54335590.9030506@lamiaworks.com.au> References: <54335590.9030506@lamiaworks.com.au> Message-ID: <543510A0.4010402@lamiaworks.com.au> T2 is a linux called T2 for take2 or try 2, it's a early ROCK Linux offshoot which was itself an offshoot from LFS as I understand it. T2 has been around for quite a number of years now, url for everything is via t2-project.org and the origonal Puppy Linux's came from it. I'm in the early stages of working on a new t2 puppy called t290 which stands for t2 trunk 9.0 since Barry Kauler has really retired and I don't want to take over his puppy 'names'. My only warning is it's close to bleeding edge. It's also downloadable via svn so it's easy to setup and play. Building is done in up to 9 toolchain layers for all their platforms / packages and it is designed and seems to work happily and to be able to cross-build from any to any. Rene has quite a pile of info and most is available, he's also a nice guy and answers silly questions sensably, but you may be told to rt*m as he expects you to at least have done that first. Layer 9 rebuilds everything in the final format and unless you are pendantic it is unnecessary as it's all built and assembled before that once anyway. Most of it's actually in scripts, so it's all legable as long as you can understand scripting (:-) and I do think you of all people do :-)) and that's why I thought it might give you some ideas from a different perspective. regards to all -------- Original Message -------- Subject: toolchains Date: Tue, 07 Oct 2014 13:53:04 +1100 From: scsijon To: aboriginal at lists.landley.net > > Also, I might want to make an external toolchain building project that > does newer toolchains. I wouldn't distribute binaries of those (GPLv3 is > a proprietary license I don't want to get on me) but buildroot > deprecated and _removed_ its native toolchain code, and crosstool-ng > apparently decided not to go there, and aboriginal needs BOTH cross and > native toolchains to do its thing, so... might be worth having a quick look at how T2 does theirs in building T2 then, as they can go down 9 layers (although usually only 5 or 7 are needed) of toolchain to do both. 1412763808.0 From rob at landley.net Fri Oct 17 20:14:38 2014 From: rob at landley.net (Rob Landley) Date: Fri, 17 Oct 2014 15:14:38 -0500 Subject: [Aboriginal] static compiles Message-ID: <544178AE.9090406@landley.net> Your message to held for approval and the administrative web ui isn't any faster than the darn web archive. (I submitted a ticket to dreamhost about this but a tech poked it to make it work and then a different tech said "delay? what delay" and closed the ticket. Sigh. Gotta do it again I suppose...) > Hello List! > > I've been trying for weeks to get a working static compile of samba3 for arm. > I have failed with a cross-compiler (sourcery toolchain) and tonight aboriginal. I built samba natively once upon a time (2006) following the "beyond linux from scratch" instructions. I could try again... > Posting to the samba listservs offers zero help. I end up with dynamically linked > code every time. Has anyone here successfully built and deployed a static build of > samba3? Hmmm, don't think I tried static, but there is one easy way to force static building: delete the shared libraries from the toolchain's search directories. :) (Aboriginal is mostly statically linked, it doesn't actualy use the dynamic libraries to run the command line or the compiler, theyr'e just there to build new things that link against 'em. Delete the *.so and keep the *.a and if samba breaks, we'll have learned something...) I can take a swing at it if you'd like? > Thanks in advance! Rob 1413576878.0 From rob at landley.net Fri Oct 17 22:52:05 2014 From: rob at landley.net (Rob Landley) Date: Fri, 17 Oct 2014 17:52:05 -0500 Subject: [Aboriginal] static compiles In-Reply-To: References: <544178AE.9090406@landley.net> Message-ID: <54419D95.8070807@landley.net> On 10/17/14 16:46, Jed Evnull wrote: > That was my fault really. I submitted my post from the wrong email addy. > > If you'd like to give it a shot please do. Hopefully you'll succeed and > I'll learn something :) > > BTW, this (aboriginal) is a pretty cool tool. I'm glad I discovered it, > I think it will make my life a bit easier, even beyond damn samba. Thanks. I haven't been promoting it for a couple years because it's more or less done and it works. (Ever since the 1.0 release it does what it says on the tin: rebuilds itself under itself and build linux from scratch natively.) I'm slowly replacing busybox with toybox, and replacing uclibc with musl-libc, and when both are done I suppose that'll be 2.0. I'm also chipping away at moving the simple-root-filesystem into initramfs and making the native-compiler live in /dev/hda and be spliced into the root filesystem by the init script (with bind mounts and symlinks), but I haven't worked out quite how I want that to look design-wise yet. The Linux From Scratch automated build control image I have (http://ladnley.net/aboriginal/control-images) is 6.8, I should upgrade that to at least 7.4. It's on the todo list. :) But most of my development effort right now is going into toybox. Aboriginal still uses the following busybox commands that aren't in toybox defconfig: awk bzip2 dd diff expr fdisk ftpd ftpget ftpput gzip less man pgrep ping pkill ps route sed sh sha512sum tar test tr unxz vi wget xzcat It's not a huge list, but some of 'em (awk, sh, vi) are kinda fairly large todo items... Rob P.S. I met a samba dev at Texas LinuxFest who said that implementing a mini samba server in toybox, just using the newest iteration of the spec with case sensitive posix semantics, wouldn't be that hard. Alas, he meant not hard for _him_. When I sent a follow-up email he pointed me at: https://wiki.samba.org/index.php/SMB3-Linux http://www.samba.org/samba/CIFS_POSIX_extensions.html https://wiki.samba.org/index.php/UNIX_Extensions Which has yet to be enlightening... 1413586325.0 From stephen.n.turner at gmail.com Sat Oct 18 00:06:44 2014 From: stephen.n.turner at gmail.com (stephen Turner) Date: Fri, 17 Oct 2014 20:06:44 -0400 Subject: [Aboriginal] static compiles In-Reply-To: <54419D95.8070807@landley.net> References: <544178AE.9090406@landley.net> <54419D95.8070807@landley.net> Message-ID: All this talk about toybox and aborigional reminded me of your tcc fork. Do you plan on building that out into an embedded gcc compatible compiler after your toybox work and aboriginal update settles down a bit? Say after aboriginal 2.0 and tb 1.0? Thanks, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Sat Oct 18 02:01:09 2014 From: rob at landley.net (Rob Landley) Date: Fri, 17 Oct 2014 21:01:09 -0500 Subject: [Aboriginal] static compiles In-Reply-To: References: <544178AE.9090406@landley.net> <54419D95.8070807@landley.net> Message-ID: <5441C9E5.90204@landley.net> On 10/17/14 19:06, stephen Turner wrote: > All this talk about toybox and aborigional reminded me of your tcc fork. > Do you plan on building that out into an embedded gcc compatible > compiler after your toybox work and aboriginal update settles down a > bit? Say after aboriginal 2.0 and tb 1.0? After toybox hits 1.0, my vaguely planned next project is to glue tinycc's frontend to qemu tcg's backend to make qcc, yes. But it's far enough in the future to be a nebulous "I should do that" with no attached schedule. I'd love it if somebody else did it instead. :) > Thanks, > Stephen Rob 1413597669.0 From stephen.n.turner at gmail.com Tue Oct 21 17:18:20 2014 From: stephen.n.turner at gmail.com (stephen Turner) Date: Tue, 21 Oct 2014 13:18:20 -0400 Subject: [Aboriginal] qcc Message-ID: one reason im curious about your qcc project is I feel gcc has gown beyond its scope. this may not actually be the case however i feel GCC should only be a c and c++ compiler (Its variants like obj c is acceptable in my mind) and i would very much like to see someone not only rebuild GCC and scale it back to the C,C++ family of code but also change the licensing as I have grown rather un-fond of anything free-software-foundation affiliated after the busybox scandals. I actually would like to see more projects take your licensing mentality with toybox, while yes commercial products would be created from it and resold you would also receive support from some as well who had that vested interest in seeing it succeed. For a moment i looked at the BSD kernel and line of code but my experiences with BSD were not happy ones as it frequently corrupted the file system and felt more like open source windows then locked down unix to me. For a compiler I considered clang but it uses too much code and programs and seems to be a more bloated gcc with a better license. Am i missing a nice project in regards to replacing gnu make, gcc, and binutils? Im also interested in a diet linux kernel if anyone has heard or seen such a thing. (not counting the 2.6 series) Thanks all, Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Wed Oct 22 16:42:21 2014 From: rob at landley.net (Rob Landley) Date: Wed, 22 Oct 2014 11:42:21 -0500 Subject: [Aboriginal] [Toybox] big endian problems In-Reply-To: References: Message-ID: <5447DE6D.6020101@landley.net> On 10/22/14 09:25, James McMechan wrote: > I was trying to do a multi-architecture buildall and it blew up on the 2nd architecture on both sparc and ppc it seems the toybox md5sum sha1sum are not big endian safe, i have not puzzled out the logic yet. Sigh. It _was_ bigendian safe, before I applied the unroll patch to speed it up back in may. I have a second unroll patch applied to my local tree that speeds it up further, but it's just too ugly for words. I've been meaning to poke at this and try to clean up the faster version, but getting it to be both simple and fast is _hard_, and haven't made a big enough block of time to sit down and stare at it yet. I hadn't done a proper retest because I wasn't done changing it. My bad, sorry. I'll build a fresh powerpc test image here and at least fix the big endian failure today. > Seagate GoFlex Home ARM 1.2GHz kirkwood 5te 128MB works > required chmod 666 /dev/null and then 'ln -s libc-2.18.so libc.so.0' so native > compiler would build under arch linux Um, did you make this change _to_ arch linux? (Confused, the aboriginal linux system image I have lying around already has /dev/null chmod 666, and libc.so.0 is a symlink to libuClibc-0.9.33.2.so. Linking glibc to libc.so.0 is... ouch? > took 287m for a single arch compile > > > my other systems are still in need of work > AMD Athlon64 - power supply replacement > Intel P75 24MB - networking problems > hp sh3 32MB - have not yet got aboriginal to build for sh3 Oh wow, you have an sh3 test system? I'm currently trying to get aboriginal to build for sh2, which is nommu and thus weird. (I've got a little xylinx fpga here with an sh2 bitstream, and an old code sourcery sh2 toolchain hooked into a buildroot fork with a kernel and such.) I've already got sh4 working in aboriginal, so collecting the whole set would be nice on general principles. Adding sh2 and sh3 support to qemu is also on the todo list. I _think_ it's mostly a question of chopping sh4 down to the earlier/smaller instruction sets (and disabling the mmu for sh2), but I have a giant PDF to read through to see what the actual differences are... > TP-Link mr3020 - aboriginal will build MIPS, but static binaries do not run on openwrt kernel > hoo-too Tripmate Elite - also MIPS not yet tested mips has a sort of oabi/eabi thing going on, where the old mipsr4k binaries I'm building (with the hard 256 meg memory constraint) are being replaced by "mips32" which is some confusing thing I need to read up on and has some kind of "kernel space code and userspace code aren't the same thing" weirdness going on that I got half an explanation of and don't understand. If anybody has a decent explanation of that lying around, I'd love to add it to the link collection. I never properly finished: http://landley.net/aboriginal/architectures.html Because I don't _know_ this information, and what research I did do is a bit stale now... Rob 1413996141.0 From owen.shepherd at e43.eu Thu Oct 23 00:16:06 2014 From: owen.shepherd at e43.eu (Owen Shepherd) Date: Thu, 23 Oct 2014 01:16:06 +0100 Subject: [Aboriginal] [Toybox] big endian problems In-Reply-To: <5447DE6D.6020101@landley.net> References: <5447DE6D.6020101@landley.net> Message-ID: <544848C6.7040605@e43.eu> > Rob Landley > 22 October 2014 17:42 > On 10/22/14 09:25, James McMechan wrote: >> I was trying to do a multi-architecture buildall and it blew up on the 2nd architecture on both sparc and ppc it seems the toybox md5sum sha1sum are not big endian safe, i have not puzzled out the logic yet. > > Sigh. It _was_ bigendian safe, before I applied the unroll patch to > speed it up back in may. > > I have a second unroll patch applied to my local tree that speeds it up > further, but it's just too ugly for words. I've been meaning to poke at > this and try to clean up the faster version, but getting it to be both > simple and fast is _hard_, and haven't made a big enough block of time > to sit down and stare at it yet. > > I hadn't done a proper retest because I wasn't done changing it. My bad, > sorry. I'll build a fresh powerpc test image here and at least fix the > big endian failure today. > >> Seagate GoFlex Home ARM 1.2GHz kirkwood 5te 128MB works >> required chmod 666 /dev/null and then 'ln -s libc-2.18.so libc.so.0' so native >> compiler would build under arch linux > > Um, did you make this change _to_ arch linux? (Confused, the aboriginal > linux system image I have lying around already has /dev/null chmod 666, > and libc.so.0 is a symlink to libuClibc-0.9.33.2.so. Linking glibc to > libc.so.0 is... ouch? > >> took 287m for a single arch compile >> >> >> my other systems are still in need of work >> AMD Athlon64 - power supply replacement >> Intel P75 24MB - networking problems >> hp sh3 32MB - have not yet got aboriginal to build for sh3 > > Oh wow, you have an sh3 test system? > > I'm currently trying to get aboriginal to build for sh2, which is nommu > and thus weird. (I've got a little xylinx fpga here with an sh2 > bitstream, and an old code sourcery sh2 toolchain hooked into a > buildroot fork with a kernel and such.) I've already got sh4 working in > aboriginal, so collecting the whole set would be nice on general principles. > > Adding sh2 and sh3 support to qemu is also on the todo list. I _think_ > it's mostly a question of chopping sh4 down to the earlier/smaller > instruction sets (and disabling the mmu for sh2), but I have a giant PDF > to read through to see what the actual differences are... > >> TP-Link mr3020 - aboriginal will build MIPS, but static binaries do not run on openwrt kernel >> hoo-too Tripmate Elite - also MIPS not yet tested > > mips has a sort of oabi/eabi thing going on, where the old mipsr4k > binaries I'm building (with the hard 256 meg memory constraint) are > being replaced by "mips32" which is some confusing thing I need to read > up on and has some kind of "kernel space code and userspace code aren't > the same thing" weirdness going on that I got half an explanation of and > don't understand. > > If anybody has a decent explanation of that lying around, I'd love to > add it to the link collection. I never properly finished: > > http://landley.net/aboriginal/architectures.html > > Because I don't _know_ this information, and what research I did do is a > bit stale now... > > Rob I don't have any info on MIPS ABI transitions, but I do have a few comments and corrections to make to that page (mostly regarding ARM, but a few other historical trivia): * ARMv5 didn't make Thumb mandatory (hence ARMv5T); that was ARMv6 * Thumb-2 was actually an ARMv6 extension (ARMv6T2) * ARMv7-M also have a completely different exception model (ARMv6-M is a further stripped down version of ARMv7-M, not actually a predecessor). The M stands for microcontroller (much like the v7-R variant stands for Realtime, of the hard realtime sort). Being a microcontroller arch, backwards compatibility is pretty unimportant. * Big vs Little endian is a runtime distinction as well (APSR contains two bits - BE8 and BE32 - which can be used to switch into one of the two big endian modes, depending upon which your processor supports. BE8 is the one all modern processors support, BE32 is the one all older processors support, IIRC). Nobody that I know of would use "armv4tl" as an architecture designator * The ABI commonly called "OABI" is actually an old, deprecated version of the EABI (it was deprecated because it didnt' interwork with Thumb code, or indeed work with Thumb very well at all). Linux took the opportunity to rework its' system call ABI at the same time. You can run EABI software on ARMv4 (no Thumb), with some caveats (you need to translate all BX instructions into MOV PC instructions) * Motorola didn't get their engineers back in their lawsuit against MOS Technologies. The eventual settlement was that MOS would discontinue the 6501, a 6800 pin-compatible variant of the 6502 * Following on from this, the 68000 was the successor to (and designed by the same team as) the 6809, Motorola's "6800 v2", done after the engineers left to found MOS (several of which would later move to the Western Design Center, which produced the 65816. WDC are an interesting example of did something two decades ago, still living entirely on the results of that thing) * The Acorn BBC Micro was a 6502 based machine. ARM was developed for its' 32-bit successor. * AArch64 is a completely revised architecture. In particular, it has a new, cleaner instruction set; the system register set has been redesigned; the whole privilege level and hypervisor functionality has been redone; the general purpose register file has been enlarged and all special purpose registers removed (SP is no longer in the register file, for one). I wouldn't be so sure of a merge. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: compose-unknown-contact.jpg Type: image/jpeg Size: 770 bytes Desc: not available URL: From luto at amacapital.net Thu Oct 23 00:51:05 2014 From: luto at amacapital.net (Andy Lutomirski) Date: Wed, 22 Oct 2014 17:51:05 -0700 Subject: [Aboriginal] [Toybox] big endian problems In-Reply-To: <544848C6.7040605@e43.eu> References: <5447DE6D.6020101@landley.net> <544848C6.7040605@e43.eu> Message-ID: One more minor note: > The kernel, C library, and compiler must all agree which ABI is in use or the binaries won't run. This isn't quite true. You can build a kernel that supports OABI and EABI. The result is worse performance (the syscall entry code needs to read the syscall instruction, wasting a dcache line) and missing features (at least seccomp filters and audit are unavailable because no cares enough to fix an ABI glitch). --Andy 1414025465.0 From hoan at wanadoo.fr Thu Oct 23 07:20:35 2014 From: hoan at wanadoo.fr (wj) Date: Thu, 23 Oct 2014 09:20:35 +0200 Subject: [Aboriginal] [Toybox] big endian problems In-Reply-To: <544848C6.7040605@e43.eu> References: <5447DE6D.6020101@landley.net> <544848C6.7040605@e43.eu> Message-ID: <1414048835.1939.4.camel@wj-P17G> interesting really ! It reminds me to my first "wrapping cabling" the 6800 ... time ago to build a C.A.M.A.C compatible micro for data acquisition !!!! ( transition from programming on ibm360 with triodes pentodes as room heater ) On jeu., 2014-10-23 at 01:16 +0100, Owen Shepherd wrote: > > > > > Rob Landley > > 22 October 2014 17:42 > > On 10/22/14 09:25, James McMechan wrote: > > > I was trying to do a multi-architecture buildall and it blew up on the 2nd architecture on both sparc and ppc it seems the toybox md5sum sha1sum are not big endian safe, i have not puzzled out the logic yet. > > > > Sigh. It _was_ bigendian safe, before I applied the unroll patch to > > speed it up back in may. > > > > I have a second unroll patch applied to my local tree that speeds it up > > further, but it's just too ugly for words. I've been meaning to poke at > > this and try to clean up the faster version, but getting it to be both > > simple and fast is _hard_, and haven't made a big enough block of time > > to sit down and stare at it yet. > > > > I hadn't done a proper retest because I wasn't done changing it. My bad, > > sorry. I'll build a fresh powerpc test image here and at least fix the > > big endian failure today. > > > > > Seagate GoFlex Home ARM 1.2GHz kirkwood 5te 128MB works > > > required chmod 666 /dev/null and then 'ln -s libc-2.18.so libc.so.0' so native > > > compiler would build under arch linux > > > > Um, did you make this change _to_ arch linux? (Confused, the aboriginal > > linux system image I have lying around already has /dev/null chmod 666, > > and libc.so.0 is a symlink to libuClibc-0.9.33.2.so. Linking glibc to > > libc.so.0 is... ouch? > > > > > took 287m for a single arch compile > > > > > > > > > my other systems are still in need of work > > > AMD Athlon64 - power supply replacement > > > Intel P75 24MB - networking problems > > > hp sh3 32MB - have not yet got aboriginal to build for sh3 > > > > Oh wow, you have an sh3 test system? > > > > I'm currently trying to get aboriginal to build for sh2, which is nommu > > and thus weird. (I've got a little xylinx fpga here with an sh2 > > bitstream, and an old code sourcery sh2 toolchain hooked into a > > buildroot fork with a kernel and such.) I've already got sh4 working in > > aboriginal, so collecting the whole set would be nice on general principles. > > > > Adding sh2 and sh3 support to qemu is also on the todo list. I _think_ > > it's mostly a question of chopping sh4 down to the earlier/smaller > > instruction sets (and disabling the mmu for sh2), but I have a giant PDF > > to read through to see what the actual differences are... > > > > > TP-Link mr3020 - aboriginal will build MIPS, but static binaries do not run on openwrt kernel > > > hoo-too Tripmate Elite - also MIPS not yet tested > > > > mips has a sort of oabi/eabi thing going on, where the old mipsr4k > > binaries I'm building (with the hard 256 meg memory constraint) are > > being replaced by "mips32" which is some confusing thing I need to read > > up on and has some kind of "kernel space code and userspace code aren't > > the same thing" weirdness going on that I got half an explanation of and > > don't understand. > > > > If anybody has a decent explanation of that lying around, I'd love to > > add it to the link collection. I never properly finished: > > > > http://landley.net/aboriginal/architectures.html > > > > Because I don't _know_ this information, and what research I did do is a > > bit stale now... > > > > Rob > I don't have any info on MIPS ABI transitions, but I do have a few > comments and corrections to make to that page (mostly regarding ARM, > but a few other historical trivia): > * ARMv5 didn't make Thumb mandatory (hence ARMv5T); that was > ARMv6 > * Thumb-2 was actually an ARMv6 extension (ARMv6T2) > * ARMv7-M also have a completely different exception model > (ARMv6-M is a further stripped down version of ARMv7-M, not > actually a predecessor). The M stands for microcontroller > (much like the v7-R variant stands for Realtime, of the hard > realtime sort). Being a microcontroller arch, backwards > compatibility is pretty unimportant. > * Big vs Little endian is a runtime distinction as well (APSR > contains two bits - BE8 and BE32 - which can be used to switch > into one of the two big endian modes, depending upon which > your processor supports. BE8 is the one all modern processors > support, BE32 is the one all older processors support, IIRC). > Nobody that I know of would use "armv4tl" as an architecture > designator > * The ABI commonly called "OABI" is actually an old, deprecated > version of the EABI (it was deprecated because it didnt' > interwork with Thumb code, or indeed work with Thumb very well > at all). Linux took the opportunity to rework its' system call > ABI at the same time. You can run EABI software on ARMv4 (no > Thumb), with some caveats (you need to translate all BX > instructions into MOV PC instructions) > * Motorola didn't get their engineers back in their lawsuit > against MOS Technologies. The eventual settlement was that MOS > would discontinue the 6501, a 6800 pin-compatible variant of > the 6502 > * Following on from this, the 68000 was the successor to (and > designed by the same team as) the 6809, Motorola's "6800 v2", > done after the engineers left to found MOS (several of which > would later move to the Western Design Center, which produced > the 65816. WDC are an interesting example of did something two > decades ago, still living entirely on the results of that > thing) > * The Acorn BBC Micro was a 6502 based machine. ARM was > developed for its' 32-bit successor. > * AArch64 is a completely revised architecture. In particular, > it has a new, cleaner instruction set; the system register set > has been redesigned; the whole privilege level and hypervisor > functionality has been redone; the general purpose register > file has been enlarged and all special purpose registers > removed (SP is no longer in the register file, for one). I > wouldn't be so sure of a merge. > _______________________________________________ > Aboriginal mailing list > Aboriginal at lists.landley.net > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net 1414048835.0 From james_mcmechan at hotmail.com Fri Oct 24 21:27:46 2014 From: james_mcmechan at hotmail.com (James McMechan) Date: Fri, 24 Oct 2014 14:27:46 -0700 Subject: [Aboriginal] [Toybox] big endian problems In-Reply-To: <5447DE6D.6020101@landley.net> References: , <5447DE6D.6020101@landley.net> Message-ID: On 10/22/14 11:21, Rob Landley wrote: > On 10/22/14 09:25, James McMechan wrote: >> I was trying to do a multi-architecture buildall and it blew up on the >> 2nd architecture on both sparc and ppc it seems the toybox md5sum >> sha1sum are not big endian safe, i have not puzzled out the logic yet. > > Sigh. It _was_ bigendian safe, before I applied the unroll patch to > speed it up back in may. > > I have a second unroll patch applied to my local tree that speeds it up > further, but it's just too ugly for words. I've been meaning to poke at > this and try to clean up the faster version, but getting it to be both > simple and fast is _hard_, and haven't made a big enough block of time > to sit down and stare at it yet. > > I hadn't done a proper retest because I wasn't done changing it. My bad, > sorry. I'll build a fresh powerpc test image here and at least fix the > big endian failure today. > No hurry from my side, I just stuck a working version in host-tools for PPC and SPARC. I was just trying to isolate the problem, so it did not get lost. >> Seagate GoFlex Home ARM 1.2GHz kirkwood 5te 128MB works >> required chmod 666 /dev/null and then 'ln -s libc-2.18.so libc.so.0' so native >> compiler would build under arch linux > > Um, did you make this change _to_ arch linux? (Confused, the aboriginal > linux system image I have lying around already has /dev/null chmod 666, > and libc.so.0 is a symlink to libuClibc-0.9.33.2.so. Linking glibc to > libc.so.0 is... ouch? > yep, I made the changes to arch linux's /dev/null and /lib/libc.so.0 -> /lib/libc-2.18.so for some reason host tools wanted that in order to build native compiler I was building armv5l first so maybe it got confused, I removed the symlink and built i686 on arm to see if it reoccurred but i686 built fine without the symlink (303m). building armv5l without the symlink blows up again for example: config.status: executing default-1 commands config.status: executing default commands make: error while loading shared libraries: libc.so.0: cannot open shared object file: No such file or directory sh ../libtool --tag CXX --tag disable-shared --mode=compile armv5l-c++ -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/../gcc -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/build-gcc/armv5l-unknown-linux-gnueabi/libstdc++-v3/include/armv5l-unknown-linux-gnueabi -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/build-gcc/armv5l-unknown-linux-gnueabi/libstdc++-v3/include -I/home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/libsupc++ -fno-implicit-templates -prefer-pic -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOURCE -c -o del_op.lo /home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/libsupc++/del_op.cc /home/mcmechan/aboriginal-1.2.9/build/temp-armv5l/gcc-core/libstdc++-v3/libsupc++/del_op.cc:45: error: expected constructor, destructor, or type conversion before 'void' Makefile:519: recipe for target 'del_op.lo' failed make: *** [del_op.lo] Error 1 Exiting due to errors (armv5l native-compiler gcc-g++) real 85m41.170s user 70m46.050s sys 5m38.270s real 228m58.799s user 193m1.060s sys 15m3.910s kind of painful 3h 48m into the compile and 4h 47m for the successful compile most of my faster ARM systems are doing other stuff e.g. phones/tablets but a NAS is powered on for days normally so it can spend lots of time compiling. >> took 287m for a single arch compile >> >> >> my other systems are still in need of work >> AMD Athlon64 - power supply replacement >> Intel P75 24MB - networking problems >> hp sh3 32MB - have not yet got aboriginal to build for sh3 > > Oh wow, you have an sh3 test system? > The HP 660LX Palmtop PC is actually a quite nice little computer currently I can run jlime.org linux on it but that is quite old at 2.6.17 It has a 640x240 touch screen with stylus and full keyboard and PCMCIA (but Yenta chipset non-cardbus cards only), and a compact flash slot for mass storage, a 75MHz sh3 and 32MB. More then my father's pentium 75 laptop expanded to 24MB the gcc-3.4.5/glibc-2.3.5 crosstools build environment for jlime is of course the usual hairball. > I'm currently trying to get aboriginal to build for sh2, which is nommu > and thus weird. (I've got a little xylinx fpga here with an sh2 > bitstream, and an old code sourcery sh2 toolchain hooked into a > buildroot fork with a kernel and such.) I've already got sh4 working in > aboriginal, so collecting the whole set would be nice on general principles. > no-MMU is more old school and painful than weird ;) I got started on systems before MMU's were so common on microprocessors, I built a lot of realtime systems starting with both 68000 and 80186 boards using 128KiB RAM later we maxed them out at 512KB per processor board, getting multiple both big and little endian processors to use shared memory and locks at the same time was interesting... Ah for the days of yester-year when you could spend a pile of money and have a multi-user system without a MMU we did eventually upgrade to a development system with a 68020 and MMU and later upgraded from SCCS to CVS which is much much nicer. That also got rid of the 8" floppies and 8" hard disks at a generous 40MB > Adding sh2 and sh3 support to qemu is also on the todo list. I _think_ > it's mostly a question of chopping sh4 down to the earlier/smaller > instruction sets (and disabling the mmu for sh2), but I have a giant PDF > to read through to see what the actual differences are... > >> TP-Link mr3020 - aboriginal will build MIPS, but static binaries do not run on openwrt kernel >> hoo-too Tripmate Elite - also MIPS not yet tested > > mips has a sort of oabi/eabi thing going on, where the old mipsr4k > binaries I'm building (with the hard 256 meg memory constraint) are > being replaced by "mips32" which is some confusing thing I need to read > up on and has some kind of "kernel space code and userspace code aren't > the same thing" weirdness going on that I got half an explanation of and > don't understand. > I have just brushed up a bit on MIPS again I used to work with them a little I think it was a crimson honking big rack with lots of fans and big twist-lock 220V 30A power connectors for the racks which alas did not have the colored panel just big SGI brown doors, the personal Indigo we later used as a system console did have the coloured case in sort of blue purple. Hunh, looks like what we had was a SGI SkyWriter 4D/510 (crimson) R3000 system which could also have upto 256MB if you maxed out the memory boards in the rack with 4M SIMMs and the first console was likely a 4D/35 Personal IRIS also R3000. Even the Indigo when it switched to blackjack with standard 72pin SIMM could do 384MB and that was about 1991-3 and it was full 64 bit using R4000 MIPS-III the 32bit R3000s from the very first Indigos was from 1988 and used MIPS-I and could only do 96MB with SGI memory modules. According to some of the notes for more than 384MB you need to boot a 64bit kernel MIPS32 looks like MIPS-II + bits from MIPS-III, MIPS-IV & MIPS-V but without the 64bit mode MIPS-III (R4000) and later instruction sets all had. The Indy low cost pizzabox used FPM SIMMs but could only go up to 8x32MB for 256MB Pretty much all others of the ones using standard FPM SIMMs could take more memory even back in the 1990s where is this hard 256MB limit from? > If anybody has a decent explanation of that lying around, I'd love to > add it to the link collection. I never properly finished: > > http://landley.net/aboriginal/architectures.html > > Because I don't _know_ this information, and what research I did do is a > bit stale now... > > Rob > _______________________________________________ > Toybox mailing list > Toybox at lists.landley.net > http://lists.landley.net/listinfo.cgi/toybox-landley.net 1414186066.0 From ibid.ag at gmail.com Sat Oct 25 00:08:23 2014 From: ibid.ag at gmail.com (Isaac Dunham) Date: Fri, 24 Oct 2014 17:08:23 -0700 Subject: [Aboriginal] [Toybox] big endian problems In-Reply-To: References: <5447DE6D.6020101@landley.net> Message-ID: <20141025000822.GA3146@newbook> On Fri, Oct 24, 2014 at 02:27:46PM -0700, James McMechan wrote: > >> TP-Link mr3020 - aboriginal will build MIPS, but static binaries do not run on openwrt kernel > >> hoo-too Tripmate Elite - also MIPS not yet tested > > > > mips has a sort of oabi/eabi thing going on, where the old mipsr4k > > binaries I'm building (with the hard 256 meg memory constraint) are > > being replaced by "mips32" which is some confusing thing I need to read > > up on and has some kind of "kernel space code and userspace code aren't > > the same thing" weirdness going on that I got half an explanation of and > > don't understand. > > I can't explain that, but OpenWRT builds kernels without FPU emulation, meaning that most MIPS routers need a soft-float ABI. > I have just brushed up a bit on MIPS again I used to work with them a little > I think it was a crimson honking big rack with lots of fans and big twist-lock > 220V 30A power connectors for the racks which alas did not have the colored > panel just big SGI brown doors, the personal Indigo we later used as a system console did > have the coloured case in sort of blue purple. Hunh, looks like what we had was > a SGI SkyWriter 4D/510 (crimson) R3000 system which could also have upto 256MB if you > maxed out the memory boards in the rack with 4M SIMMs and the first console was > likely a 4D/35 Personal IRIS also R3000. > Even the Indigo when it switched to blackjack with standard 72pin SIMM could > do 384MB and that was about 1991-3 and it was full 64 bit using R4000 MIPS-III the > 32bit R3000s from the very first Indigos was from 1988 and used MIPS-I and could only do > 96MB with SGI memory modules. > According to some of the notes for more than 384MB you need to boot a 64bit kernel > MIPS32 looks like MIPS-II + bits from MIPS-III, MIPS-IV & MIPS-V but without the 64bit > mode MIPS-III (R4000) and later instruction sets all had. > The Indy low cost pizzabox used FPM SIMMs but could only go up to 8x32MB for 256MB > Pretty much all others of the ones using standard FPM SIMMs could take more memory > even back in the 1990s where is this hard 256MB limit from? > http://www.linux-mips.org/wiki/Highmem says it's basically that only 512MB are theoretically addresseable as lowmem, and some of that is reserved so only half can be used. HTH, Isaac Dunham 1414195703.0 From rob at landley.net Sat Oct 25 02:21:06 2014 From: rob at landley.net (Rob Landley) Date: Fri, 24 Oct 2014 21:21:06 -0500 Subject: [Aboriginal] [Toybox] big endian problems In-Reply-To: <20141025000822.GA3146@newbook> References: <5447DE6D.6020101@landley.net> <20141025000822.GA3146@newbook> Message-ID: <544B0912.8060807@landley.net> On 10/24/14 19:08, Isaac Dunham wrote: > On Fri, Oct 24, 2014 at 02:27:46PM -0700, James McMechan wrote: >>>> TP-Link mr3020 - aboriginal will build MIPS, but static binaries do not run on openwrt kernel >>>> hoo-too Tripmate Elite - also MIPS not yet tested >>> >>> mips has a sort of oabi/eabi thing going on, where the old mipsr4k >>> binaries I'm building (with the hard 256 meg memory constraint) are >>> being replaced by "mips32" which is some confusing thing I need to read >>> up on and has some kind of "kernel space code and userspace code aren't >>> the same thing" weirdness going on that I got half an explanation of and >>> don't understand. >>> > > I can't explain that, but OpenWRT builds kernels without FPU emulation, > meaning that most MIPS routers need a soft-float ABI. I honestly don't remember what the aboriginal mips target is currently using (whatever gcc 4.2.1 defaults to), but there's a GCC_FLAGS= entry in sources/targets/mips that we can feed other stuff to. (And tweak the uclibc and kernel configs to match...) I really need to get everything switched over to musl by default before fiddling with this sort of thing much more though. Another round of toolchain symbol visibility decision path tweaks. (The guts of gcc are never a fun place to hang out...) >> According to some of the notes for more than 384MB you need to boot a 64bit kernel >> MIPS32 looks like MIPS-II + bits from MIPS-III, MIPS-IV & MIPS-V but without the 64bit >> mode MIPS-III (R4000) and later instruction sets all had. >> The Indy low cost pizzabox used FPM SIMMs but could only go up to 8x32MB for 256MB >> Pretty much all others of the ones using standard FPM SIMMs could take more memory >> even back in the 1990s where is this hard 256MB limit from? > > http://www.linux-mips.org/wiki/Highmem > says it's basically that only 512MB are theoretically addresseable as lowmem, > and some of that is reserved so only half can be used. Somebody explained to me (many moons ago, in private email) that mips uses bits from the 32 bit physical pointers as status bits instead of having enough bits in the page tables, so only 512 megs of it is left as actual address space, half of which is used for I/O memory (more or less another status bit). So that's 256 megs actual physical memory. (Of course this explanation could be wrong...) Rob 1414203666.0 From dahalls at gmail.com Mon Oct 27 10:16:25 2014 From: dahalls at gmail.com (David Halls) Date: Mon, 27 Oct 2014 10:16:25 +0000 Subject: [Aboriginal] USE_TLS Message-ID: Hi- I'm having a go at compiling Go but get these error messages: Program uses unsupported TLS data! I guess this is because uClibc isn't compiled with TLS support (USE_TLS)? Is something bad likely to happen if I recompile uClibc with USE_TLS? Many thanks David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Mon Oct 27 13:59:43 2014 From: rob at landley.net (Rob Landley) Date: Mon, 27 Oct 2014 08:59:43 -0500 Subject: [Aboriginal] Aboriginal post from dahalls@gmail.com requires approval In-Reply-To: References: Message-ID: <544E4FCF.1040704@landley.net> On 10/27/14 05:16, David Halls wrote: > Hi- > > I'm having a go at compiling Go but get these error messages: > > Program uses unsupported TLS data! > > I guess this is because uClibc isn't compiled with TLS support > (USE_TLS)? Is something bad likely to happen if I recompile uClibc with > USE_TLS? > > Many thanks > > David It should work. You can add it in sources/baseconfig-uClibc to switch it on for all targets, or in the appropriate sources/targets/$FILENAME UCLIBC_CONFIG= block to switch it on for just one. (I actually thought I switched that on when I went from pthreads to nptl, but I guess not. I should switch it on for everything and regression test the linux from scratch build on all targets, but I'm also trying to switch everything over to musl-libc where it should just work out of the box once I've got the toolchain exporting the right darn symbols...) Rob 1414418383.0 From dahalls at gmail.com Tue Oct 28 00:02:28 2014 From: dahalls at gmail.com (David Halls) Date: Tue, 28 Oct 2014 00:02:28 +0000 Subject: [Aboriginal] Aboriginal post from dahalls@gmail.com requires approval In-Reply-To: <544E4FCF.1040704@landley.net> References: <544E4FCF.1040704@landley.net> Message-ID: Thanks Rob- I've added that. I've got a (probably) unrelated problem now: In file included from ../include/linux/netdevice.h:30, from ll_types.c:24: /usr/bin/../include/linux/if_packet.h:194: error: expected specifier-qualifier-list before '__aligned_u64' distcc[31196] ERROR: compile ll_types.c on localhost failed make[1]: *** [ll_types.o] Error 1 make[1]: Leaving directory `/home/iproute2/lib' This seems strange as it built fine a couple of days ago and I just started over fresh. I guess __aligned_u64 is undefined for some reason (probably an ifdef somewhere). Regards- David On 27 October 2014 13:59, Rob Landley wrote: > On 10/27/14 05:16, David Halls wrote: > > Hi- > > > > I'm having a go at compiling Go but get these error messages: > > > > Program uses unsupported TLS data! > > > > I guess this is because uClibc isn't compiled with TLS support > > (USE_TLS)? Is something bad likely to happen if I recompile uClibc with > > USE_TLS? > > > > Many thanks > > > > David > > It should work. You can add it in sources/baseconfig-uClibc to switch it > on for all targets, or in the appropriate sources/targets/$FILENAME > UCLIBC_CONFIG= block to switch it on for just one. > > (I actually thought I switched that on when I went from pthreads to > nptl, but I guess not. I should switch it on for everything and > regression test the linux from scratch build on all targets, but I'm > also trying to switch everything over to musl-libc where it should just > work out of the box once I've got the toolchain exporting the right darn > symbols...) > > Rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Tue Oct 28 01:52:15 2014 From: rob at landley.net (Rob Landley) Date: Mon, 27 Oct 2014 20:52:15 -0500 Subject: [Aboriginal] qcc In-Reply-To: References: Message-ID: <544EF6CF.3000705@landley.net> Sorry for the delay replying, I have a gazillion open windows in 8 desktops right now... On 10/21/14 12:18, stephen Turner wrote: > one reason im curious about your qcc project is I feel gcc has gown > beyond its scope. I'm sure I've expressed my opinon on this topic before, but a quick google is just finding a couple offhand comments: http://landley.net/notes-2012.html#31-05-2012 https://lkml.org/lkml/2012/6/23/197 Here's what happened: 1) gcc reduced its relevance due to copyright assignment and tight coupling, as described in: https://lwn.net/Articles/259157/ Note that Richard Stallman _explicitly_ said that he forced gcc to be a tangled monolithic hairball because he feared proprietary programs would separate the frontend from the backend and replace one or the other. (Note: LLVM did exactly this _anyway_, using a gcc frontend for a new code generator, then replacing the frontend with clang.) 2) Then gcc relicensed itself GPLv3 and hit the whole range of issues I covered in my talk here: A couple of the high points of which are at: http://landley.net/notes-2013.html#27-07-2013 The result of _that_ was Apple sponsoring LLVM development and freezing on gcc 4.2.1 and binutils 2.17 until they were ready, and removing all GPL packages from MacOS X: http://meta.ath0.com/2012/02/05/apples-great-gpl-purge/ Meanwhile BSD relaunched PCC development, https://lwn.net/Articles/255558/ Plus some oddballs like qualcomm contributing to open64 and so on, which seem to have receded again. http://www.capsl.udel.edu/conferences/open64/2008/ I gave a talk about the licensing change last year. It did more to overshadow mainline gcc development than anything since the egcs fork: http://landley.net/talks/ohio-2013.txt https://archive.org/download/OhioLinuxfest2013/24-Rob_Landley-The_Rise_and_Fall_of_Copyleft.mp3 The gcc developers were _so_ pissed about everybody sticking with the last GPLv2 releases of gcc and binutils (like Aboriginal is doing, and BSD, and Apple, and...) that they deleted original binutils 2.17 source off their website and replaced it with a tarball containing GPLv3 code: http://landley.net/notes-2013.html#11-01-2012 And of course the FSF fought it in all sorts of other ways, such as announcing that GPLv2 only was no longer an allowed license on their "savannah" sourceforge clone (but bsd and apache licenses were): https://lwn.net/Articles/176582/ When musl 1.0 happened and some twit objected to it being BSD licensed and hoped it would change _to_ gpl, I went off on the guy with three or four long link-filled posts. If you want research aboutwhy I think the GPL has outlived its usefulness, start at: https://lwn.net/Articles/591396/ 3) gcc decided to rewrite itself in C++: https://lwn.net/Articles/286539/ https://lwn.net/Articles/390016/ https://lwn.net/Articles/542457/ Which took away the one advantage they still had over llvm. At this point, building the linux kernel with llvm is an official Linux Foundation project: http://llvm.linuxfoundation.org > this may not actually be the case however i feel GCC > should only be a c and c++ compiler (Its variants like obj c is > acceptable in my mind) and i would very much like to see someone not > only rebuild GCC and scale it back to the C,C++ family of code but also > change the licensing as I have grown rather un-fond of anything > free-software-foundation affiliated after the busybox scandals. I have... opinions. :) I've also written at great length about how calling C++ a good language because it contains C is like calling a mud pie a good beverage because it contains an entire glass of water. http://landley.net/notes-2011.html#16-03-2011 http://landley.net/notes-2011.html#19-03-2011 http://landley.net/notes-2011.html#20-03-2011 The hard part of all this is _summarizing_. I can talk your ear off for hours about these things, but if you want the elevator pitch, I have to stop and think for quite a while about what to leave _out_. > I actually would like to see more projects take your licensing mentality > with toybox, while yes commercial products would be created from it and > resold you would also receive support from some as well who had that > vested interest in seeing it succeed. Worrying about "oh no, somebody will clone my thing"... that falls under "welcome to the internet". If it's open source, on a webpage, and reasonably maintained there's no _value_ in forking it. Ok, somebody will build a windows binary, repackage it with adware or malware, and put it for download (or even try to sell it). But that's basically just Windows. They'll do that to stuff like VLC which is GPL/LGPL already: https://www.videolan.org/license/ http://www.howtogeek.com/194993/the-windows-store-is-a-cesspool-of-scams-why-doesnt-microsoft-care/ > For a moment i looked at the BSD kernel and line of code but my > experiences with BSD were not happy ones as it frequently corrupted the > file system and felt more like open source windows then locked down unix > to me. My experiences with BSD haven't been happy either: http://landley.net/notes-2013.html#15-09-2013 http://landley.net/notes-2014.html#18-06-2014 http://landley.net/notes-2014.html#11-09-2014 I keep periodically trying, but it's not really a priority at hte moment. > For a compiler I considered clang but it uses too much code and programs > and seems to be a more bloated gcc with a better license. It would be really nice if pcc amounted to something. http://pcc.ludd.ltu.se/ Especially if some variant of cfront (enough to build llvm) was revived/implemented: http://marc.info/?l=pcc-list&m=141020111215576&w=2 Alas, llvm overshadowed that enough they're down to one part-time developer actually working on it. Still, it's a possibility. > Am i missing a nice project in regards to replacing gnu make, gcc, and > binutils? Im also interested in a diet linux kernel if anyone has heard > or seen such a thing. (not counting the 2.6 series) I want to do qcc because there's no _simple_ C compiler right now. I have permission from Fabrice to BSD license his code (I should ask if my "zero clause" bsd counts :) http://landley.net/notes-2012.html#14-06-2012 But since toybox relaunched I just haven't had time to work on it. This entire weekend was eaten by sed and I got like another 1/4 of it done... > Thanks all, > Stephen Rob 1414461135.0 From rob at landley.net Tue Oct 28 01:57:12 2014 From: rob at landley.net (Rob Landley) Date: Mon, 27 Oct 2014 20:57:12 -0500 Subject: [Aboriginal] Aboriginal post from dahalls@gmail.com requires approval In-Reply-To: References: <544E4FCF.1040704@landley.net> Message-ID: <544EF7F8.5050404@landley.net> On 10/27/14 19:02, David Halls wrote: > Thanks Rob- I've added that. > > I've got a (probably) unrelated problem now: > > In file included from ../include/linux/netdevice.h:30, > from ll_types.c:24: > /usr/bin/../include/linux/if_packet.h:194: error: expected > specifier-qualifier-list before '__aligned_u64' > distcc[31196] ERROR: compile ll_types.c on localhost failed > make[1]: *** [ll_types.o] Error 1 > make[1]: Leaving directory `/home/iproute2/lib' > > > This seems strange as it built fine a couple of days ago and I just > started over fresh. > I guess __aligned_u64 is undefined for some reason (probably an ifdef > somewhere). gcc -E is your friend. :) But so is sticking "#warning aardvark" into various headers to see whether or not an #ifdef case is triggering (copy 'em to writeable space and --bind mount the file back, yes bind mount works on individual files), and of course the ever-popular: gcc -E -dM - < /dev/null Which shows all the builtin #defines for your current compiler. (Works on cross compilers too!) > Regards- > David Rob 1414461432.0