From rob at landley.net  Thu Jan 10 03:12:28 2013
From: rob at landley.net (Rob Landley)
Date: Wed, 09 Jan 2013 21:12:28 -0600
Subject: [Aboriginal] Pondering an intermediate release.
Message-ID: <1357787548.4045.2@driftwood>

Each new Aboriginal Linux release has mostly followed a kernel release  
(with other package upgrades swept up into that as I get to them), but  
the ls segfault thing is just embarassing. I'm at a reasonable release  
point for toybox (fixing the ls bug and removing 3 more commands from  
baseconfig-busybox), and pondering just cutting a new Aboriginal Linux  
release using that now.

I'm testing linux-3.8-rc2 and it more or less works. (One patch tweak  
required.) I can cut the release with -rc2 or -rc3 and then cut another  
release when 3.8 proper comes out, or I can cut a second release with  
3.7. Any strong opinions one way or the other?

(As an aside, I start a new job on the 21st and there's travel involved  
so I've got about another week left to work on this stuff before  
there's some schedule interruption. That's also contributing to the  
"cut a release now" side of the scale.)

Rob
 1357787548.0

From bjorn.forsman at gmail.com  Thu Jan 10 06:56:03 2013
From: bjorn.forsman at gmail.com (=?UTF-8?Q?Bj=C3=B8rn_Forsman?=)
Date: Thu, 10 Jan 2013 07:56:03 +0100
Subject: [Aboriginal] Pondering an intermediate release.
In-Reply-To: <1357787548.4045.2@driftwood>
References: <1357787548.4045.2@driftwood>
Message-ID: <CAEYzJUFZ80M=EUTyJZYnUzqp64yyYHbg2RNv7Kj6rTGts7Qg6Q@mail.gmail.com>

On 10 January 2013 04:12, Rob Landley <rob at landley.net> wrote:
[...]
> I'm testing linux-3.8-rc2 and it more or less works. (One patch tweak
> required.) I can cut the release with -rc2 or -rc3 and then cut another
> release when 3.8 proper comes out, or I can cut a second release with 3.7.
> Any strong opinions one way or the other?

Well, this is not a strong opinion, but I'd prefer a release with 3.7
over 3.8-rc[23]. My reasoning is that the 3.7 kernel must be more
stable because it *is* released, and the 3.8 kernel is not (it's just
an early release candidate).

But if you're making an aboriginal *release candidate*, using some
3.8-rcX is totally fine (IMO).

Best regards,
Bj?rn Forsman

 1357800963.0

From bjorn.forsman at gmail.com  Thu Jan 10 07:18:48 2013
From: bjorn.forsman at gmail.com (=?UTF-8?Q?Bj=C3=B8rn_Forsman?=)
Date: Thu, 10 Jan 2013 08:18:48 +0100
Subject: [Aboriginal] Merry christmas, I have found two bugs
In-Reply-To: <1356615039.31232.11@driftwood>
References: <CAEYzJUFOwR+7TQR+COh5zrxkKjuWLzQm+sUEwHKVLbiLdR1mxg@mail.gmail.com>
	<1356615039.31232.11@driftwood>
Message-ID: <CAEYzJUGhEBsj4Q59b+MkRWgtGK9B3wDsnX_bV-iXOrj=3fnWoA@mail.gmail.com>

On 27 December 2012 14:30, Rob Landley <rob at landley.net> wrote:
> On 12/26/2012 04:23:06 PM, Bj?rn Forsman wrote:
>>
>> On 26 December 2012 22:36, Rob Landley <rob at landley.net> wrote:
>> > On 12/26/2012 02:55:04 PM, Bj?rn Forsman wrote:
>> [...]
>> >> And now I think I've found two bugs. Bug 1 is
>> >> a segmentation fault during system image boot:
>> >>
>> >> $ cd build/system-image-avmv5l
>> >> $ ./run-emulator.sh
>> >> [...]
>> >> Freeing init memory: 96K
>> >> Segmentation fault
>> >> 8139cp 0000:00:0c.0 eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
>> >> Not using distcc.
>> >> Type exit when done.
>> >> (armv5l:1) /home #
>> >>
>> >> Not sure what exactly is segfaulting, but segfault == bug to me. And
>> >> it only happens with ./run-emulator.sh, not ./dev-environment.sh.
>> >
>> > There are somewhat different code paths in the init.sh shell script so
>> > it's
>> > probably something only running in the first case. I need to rebuild the
>> > armv5l target to test this, that'll take a few minutes...
>
>
> Still grinding away on this. It's... weird.
>
> If I run_emulator.sh with KERNEL_EXTRA=init=/bin/bash and then exec
> /sbin/init.sh it does _not_ segfault. It doesn't do so with init=/bin/bash
> or init=/bin/ash. But it _does_ do so when init=/sbin/init.sh when that
> starts with #!/bin/bash or #!/bin/ash.
>
> So it only happens when the script is run as the first process. Not just as
> PID 1, as the _first_process_. If you exec a shell that execs the script, it
> doesn't segfault.
>
> So the same thing happening with two different shells, but only from a very
> specific execution environment. Is there some asynchronous kernel thread
> that happens to damage whatever's running at the time it completes? Add a
> sleep 1" before the if CPU block... no difference.
>
> Back up, confirm whether ash or bash IS running, add an ls -l /proc/self/exe
> and it says... toybox.  Sigh.  Make that ls -l /proc/1/exe (ask about the
> _shell_ not the ls process) and it says... /bin/bash. And when I switch the
> #! line to ash it... isn't segfaulting?
>
> Hang on, according to "hg diff" the initial version wasn't #!/bin/ash it was
> #!/bin/sh which points to _bash_. So I switched it from bash to bash, which
> is an invalid test. So it's NOT a bug affecting both shells (and thus
> probably some libc thing with setsid or who knows what), it's a BASH BUG.
>
> Given how old the version of bash I'm using is, and that I've already had to
> fix deep obscure bugs in it before (the backstory behind
> http://landley.net/hg/aboriginal/rev/de8e06350227 is long and epic and
> described in my blog over a course of weeks), I think the correct fix is
> #!/bin/ash (and eventually #!/bin/toysh).
>
> Rob

Oh, I forgot to say thanks for looking into this. I appreciate it.

Best regards,
Bj?rn Forsman

 1357802328.0

From rob at landley.net  Fri Jan 11 03:02:00 2013
From: rob at landley.net (Rob Landley)
Date: Thu, 10 Jan 2013 21:02:00 -0600
Subject: [Aboriginal] Pondering an intermediate release.
In-Reply-To: <CAEYzJUFZ80M=EUTyJZYnUzqp64yyYHbg2RNv7Kj6rTGts7Qg6Q@mail.gmail.com>
	(from bjorn.forsman@gmail.com on Thu Jan 10 00:56:03 2013)
Message-ID: <1357873320.32505.1@driftwood>

On 01/10/2013 12:56:03 AM, Bj?rn Forsman wrote:
> On 10 January 2013 04:12, Rob Landley <rob at landley.net> wrote:
> [...]
> > I'm testing linux-3.8-rc2 and it more or less works. (One patch  
> tweak
> > required.) I can cut the release with -rc2 or -rc3 and then cut  
> another
> > release when 3.8 proper comes out, or I can cut a second release  
> with 3.7.
> > Any strong opinions one way or the other?
> 
> Well, this is not a strong opinion, but I'd prefer a release with 3.7
> over 3.8-rc[23]. My reasoning is that the 3.7 kernel must be more
> stable because it *is* released, and the 3.8 kernel is not (it's just
> an early release candidate).

Understood, and thanks for the opinion. I'm sort of ambivalent myself,  
which is why I asked.

3.7-rc3 was just released. Personally, I find this non-release release  
thing confusing. I know that -rc1 is what the "odd" series used to be,  
and then the other -rc iterations are just Linus trying to browbeat  
people into testing it. :)

But for Aboriginal Linnux, I'm the one doing the testing on the  
kernels. The final package versions are broken on various targets all  
the time, as in "does not even compile in my configuration", and then  
"doesn't boot", and then "doesn't quite work right due to that ext4  
bug" or the time stat was broken on sparc for 3 releases to the point  
ls -l gave a date thousands of years in the future...

Release versions of kernels are useful because it gives people known  
versions to play with, where everybody syncs up and sees approximately  
the same features/bugs, and 18 months down the road it's easier to  
remember (or look up) what was in a release.

But bug fixes happen all the time, that's why we're up to 3.7.1 and  
3.6.11.

(And I sort of assume people are likely to replace the kernel if the  
actually deploy stuff, the ones I'm doing are just for qemu, not for  
actual hardware.)

> But if you're making an aboriginal *release candidate*, using some
> 3.8-rcX is totally fine (IMO).

I generally don't do release candidates. If I bother to test and tar it  
up, it's a release. If I _know_ it doesn't work, I don't make a  
release. If I find out later it's broken, I make another release, ala  
now. People can build source control snapshots at any time, so I don't  
see the point in an -rc.

However, the question I asked is a bit moot because it turns out  
there's some more stuff to fix in toybox first. (Testing for a release  
tends to find stuff wrong, and it's usually one of those pull on a  
loose thread things...) Working on that now...

Thanks,

Rob`
 1357873320.0

From rob at landley.net  Sun Jan 13 15:11:42 2013
From: rob at landley.net (Rob Landley)
Date: Sun, 13 Jan 2013 09:11:42 -0600
Subject: [Aboriginal] Aboriginal PATH gets messed up
In-Reply-To: <1358059621.25019.YahooMailNeo@web125106.mail.ne1.yahoo.com>
	(from cusbrar2@yahoo.com on Sun Jan 13 00:47:01 2013)
Message-ID: <1358089902.32505.13@driftwood>

On 01/13/2013 12:47:01 AM, chase rayfield wrote:
> Hey Rob,
> 
> I attempted to build Aboriginal just now and I get
> 
> ./download.sh: line 10: mkdir: command not found

Wild guess: you ran more/record-commands.sh then deleted build/host but  
not
build/record-commands ? (The logic for figuring out what the  
record-commands wrapper hands off to is still a bit brittle.)

If not, did you build via build.sh or via more/buildall.sh? (Let's see,  
clean pull, ./build.sh i686, and... that's going to take a while on  
this netbook.)

> if I echo the $PATH just before inside dienow() I only get  
> /root/aboriginal/build/host rather than  
> /usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3:/opt/nvidia-cg-toolkit/bin

A) You don't need to build as root, it should work fine as a normal  
user.

B) The point of host-tools.sh is to setup build/host with known  
versions of everything the build needs, and then the rest of the build  
restricts the $PATH to that if it's there. Sounds like it's setting it  
up wrong. Let's see...

(The build can skip the host-tools.sh stage. Either comment it out in  
build.sh or run the stages yourself by hand skipping that one. But that  
doesn't fix the problem, host-tools _should_ be creating a good  
build/host directory...)

> I attempted to figure out what the problem was but couldn't find  
> anything in the
> utility_functions.sh that was broken... perhaps you have some  
> suggestions or have a
> better idea about the problem.

It's finished host-tools.sh here and is grinding away at binutils. I  
just stopped it and re-ran download.sh and it's happy.

> I'm on funtoo curently switching from gentoo so I may have some  
> configuration issue
> but I haven't noticed anything elsewhere.

What are the steps you used to reproduce this? Are you building the  
latest release version or a mercurial pull? Have you built in that  
directory before, or does it do it on your first attempt in a clean  
directory?

I'm happy to debug anything I can reproduce, but I need more info to  
reproduce this...

> I switched since I got a nice little quad
> core netbook sized laptop :) Sager NP6110... 16Gb ram should work  
> great for testing
> stuff out. I mention it since you seem to enjoy that size factor but  
> not the
> customary loss in performance it did hurt the wallet a bit more  
> though X.x.

Sounds like a nice machine. I've built under funtoo before, but it was  
a while ago.

> I might get back around to testing sparc kernels if I have time....  
> someone just sent
> me a 150Mhz Hypersparc and a bunch of ram for my SS-10 so that should  
> go swimmingly.

Ooh, very nice.

I was looking up sparc64 a while ago and it's another one like powerpc  
64 where they didn't bother to do a 64 bit userspace, just 64 bit  
kernels and the very occasional application. Thus I'm not quite sure  
how to add Aboriginal support to it. (Just a toolchain? Toolchain and  
kernel using the 32 bit userspace? Except how would you build the  
"occasional" 64 bit application? Where does libc enter into this?)

   http://www.debian.org/ports/sparc/

Then again, I'm told that's changing because gcc is dropping sparc32  
support:

   http://wiki.debian.org/Sparc64

(Of course current gcc requires a C++ compiler on the host to build it,  
so here's hoping clang/pcc/open64 matures quickly.)

Rob
 1358089902.0

From idunham at lavabit.com  Mon Jan 14 07:36:16 2013
From: idunham at lavabit.com (Isaac Dunham)
Date: Sun, 13 Jan 2013 23:36:16 -0800
Subject: [Aboriginal] Aboriginal Digest, Vol 24, Issue 3
In-Reply-To: <mailman.1.1358112637.27938.aboriginal-landley.net@lists.landley.net>
References: <mailman.1.1358112637.27938.aboriginal-landley.net@lists.landley.net>
Message-ID: <20130113233616.09b4000d.idunham@lavabit.com>

On Sun, 13 Jan 2013 13:30:37 -0800
Rob Landley wrote:

> > I switched since I got a nice little quad
> > core netbook sized laptop :) Sager NP6110... 16Gb ram should work  
> > great for testing stuff out. I mention it since you seem to enjoy 
> > that size factor but not the
> > customary loss in performance it did hurt the wallet a bit more  
> > though X.x.
> 
> Sounds like a nice machine. I've built under funtoo before, but it 
> was a while ago.

Looks nice indeed, especially compared to an Atom netbook (I have an aspire one as secondary).
In my experience, an ssd is probably the first thing a ~netbook needs. 5400 RPM hard drives are miserable.  But everything is pretty limited, especially if you use bloat like the full gnu (gnu's not usable?) environment.
 
> > I might get back around to testing sparc kernels if I have time....  
> > someone just sent
> > me a 150Mhz Hypersparc and a bunch of ram for my SS-10 so that should  
> > go swimmingly.
> 
> Ooh, very nice.
> 
> I was looking up sparc64 a while ago and it's another one like powerpc  
> 64 where they didn't bother to do a 64 bit userspace, just 64 bit  
> kernels and the very occasional application. Thus I'm not quite sure  
> how to add Aboriginal support to it. (Just a toolchain? Toolchain and  
> kernel using the 32 bit userspace? Except how would you build the  
> "occasional" 64 bit application? Where does libc enter into this?)
> 
>    http://www.debian.org/ports/sparc/

Debian's approach is "multilib", but that's a bit of a mess in its own right.  You might need their patches to make it work right.
Basically, you have 
-a 32-bit toolchain, but capable of targeting both 32-bit and 64-bit
-two builds of libc, one for 64-bit, one for 32-bit
-the rest of the environment built for 32-bit

> Then again, I'm told that's changing because gcc is dropping sparc32  
> support:
> 
>    http://wiki.debian.org/Sparc64
> 
> (Of course current gcc requires a C++ compiler on the host to build it,  
> so here's hoping clang/pcc/open64 matures quickly.)

What's left for open64 to mature in your opinion? From all I've seen, there are a few places where gcc is just catching up with them.

clang seems to be making headway, but pcc seems to be at the "well, it's more active than tcc..." level. It can bootstrap at least OpenBSD, though,

> Rob

-- 
Isaac Dunham <idunham at lavabit.com>


 1358148976.0

From rob at landley.net  Mon Jan 14 13:27:17 2013
From: rob at landley.net (Rob Landley)
Date: Mon, 14 Jan 2013 07:27:17 -0600
Subject: [Aboriginal] Aboriginal Digest, Vol 24, Issue 3
In-Reply-To: <20130113233616.09b4000d.idunham@lavabit.com> (from
	idunham@lavabit.com on Mon Jan 14 01:36:16 2013)
Message-ID: <1358170037.32505.20@driftwood>

On 01/14/2013 01:36:16 AM, Isaac Dunham wrote:
> On Sun, 13 Jan 2013 13:30:37 -0800
> Rob Landley wrote:
> > Sounds like a nice machine. I've built under funtoo before, but it
> > was a while ago.
> 
> Looks nice indeed, especially compared to an Atom netbook (I have an  
> aspire one as
> secondary).
> In my experience, an ssd is probably the first thing a ~netbook  
> needs. 5400 RPM hard
> drives are miserable.  But everything is pretty limited, especially  
> if you use bloat
> like the full gnu (gnu's not usable?) environment.

I got one I could upgrade to 8 gigs of ram. Makes a big difference.

That doesn't help me reproduce this build failure, though.

> > I was looking up sparc64 a while ago and it's another one like  
> powerpc
> > 64 where they didn't bother to do a 64 bit userspace, just 64 bit
> > kernels and the very occasional application. Thus I'm not quite sure
> > how to add Aboriginal support to it. (Just a toolchain? Toolchain  
> and
> > kernel using the 32 bit userspace? Except how would you build the
> > "occasional" 64 bit application? Where does libc enter into this?)
> >
> >    http://www.debian.org/ports/sparc/
> 
> Debian's approach is "multilib", but that's a bit of a mess in its  
> own right.
> You might need their patches to make it work right.

I don't do multilib. I'm trying to set up a target environment you can  
build stuff under. If you can natively build a new Linux From Scratch  
chroot, my work is done.

> Basically, you have
> -a 32-bit toolchain, but capable of targeting both 32-bit and 64-bit
> -two builds of libc, one for 64-bit, one for 32-bit
> -the rest of the environment built for 32-bit

If I _can_ build a 64-bit only environment, I'd like to do that. That's  
how the x86-64 target works, for example. (You can add 32 bit libraries  
after the fact, by building them  natively on target.)

Last I checked uClibc didn't support it, but musl might someday.

> > Then again, I'm told that's changing because gcc is dropping sparc32
> > support:
> >
> >    http://wiki.debian.org/Sparc64
> >
> > (Of course current gcc requires a C++ compiler on the host to build  
> it,
> > so here's hoping clang/pcc/open64 matures quickly.)
> 
> What's left for open64 to mature in your opinion? From all I've seen,  
> there are a
> few places where gcc is just catching up with them.

I don't know. I'm trying to learn enough to find out. I'll probably  
have to try it and see what breaks.

> clang seems to be making headway, but pcc seems to be at the "well,  
> it's more
> active than tcc..." level. It can bootstrap at least OpenBSD, though,

Clang needs C++ on the host in order to build (but only recently wrote  
its own C++ standard library), didn't have its own binutils last I  
checked... I'll need to engage with this more at some point but it's  
not strongly luring me out of my niche yet.

Rob
 1358170037.0

From idunham at lavabit.com  Mon Jan 14 17:50:12 2013
From: idunham at lavabit.com (Isaac Dunham)
Date: Mon, 14 Jan 2013 09:50:12 -0800
Subject: [Aboriginal] Aboriginal Digest, Vol 24, Issue 3
In-Reply-To: <1358170037.32505.20@driftwood>
References: <20130113233616.09b4000d.idunham@lavabit.com>
	<1358170037.32505.20@driftwood>
Message-ID: <20130114095012.60604cb9.idunham@lavabit.com>

On Mon, 14 Jan 2013 07:27:17 -0600
Rob Landley <rob at landley.net> wrote:


> > > I was looking up sparc64 a while ago and it's another one like  
> > powerpc
> > > 64 where they didn't bother to do a 64 bit userspace, just 64 bit
> > > kernels and the very occasional application. Thus I'm not quite sure
> > > how to add Aboriginal support to it. (Just a toolchain? Toolchain  
> > and
> > > kernel using the 32 bit userspace? Except how would you build the
> > > "occasional" 64 bit application? Where does libc enter into this?)
> > >
> > >    http://www.debian.org/ports/sparc/
> > 
> > Debian's approach is "multilib", but that's a bit of a mess in its  
> > own right.
> > You might need their patches to make it work right.
> 
> I don't do multilib. I'm trying to set up a target environment you can  
> build stuff under. If you can natively build a new Linux From Scratch  
> chroot, my work is done.
> 
> > Basically, you have
> > -a 32-bit toolchain, but capable of targeting both 32-bit and 64-bit
> > -two builds of libc, one for 64-bit, one for 32-bit
> > -the rest of the environment built for 32-bit
> 
> If I _can_ build a 64-bit only environment, I'd like to do that. That's  
> how the x86-64 target works, for example. (You can add 32 bit libraries  
> after the fact, by building them  natively on target.)
> 
> Last I checked uClibc didn't support it, but musl might someday.

"it" == building only 64-bit libs when targeting 64-bit arches?
If so, that's all that musl supports; there is no automated "we think you ought to support another ABI, so we're building it also."

> > > Then again, I'm told that's changing because gcc is dropping sparc32
> > > support:
> > >
> > >    http://wiki.debian.org/Sparc64
> > >
> > > (Of course current gcc requires a C++ compiler on the host to build  
> > it,
> > > so here's hoping clang/pcc/open64 matures quickly.)
> > 
> > What's left for open64 to mature in your opinion? From all I've seen,  
> > there are a
> > few places where gcc is just catching up with them.
> 
> I don't know. I'm trying to learn enough to find out. I'll probably  
> have to try it and see what breaks.
> 
> > clang seems to be making headway, but pcc seems to be at the "well,  
> > it's more
> > active than tcc..." level. It can bootstrap at least OpenBSD, though,
> 
> Clang needs C++ on the host in order to build (but only recently wrote  
> its own C++ standard library), didn't have its own binutils last I  
> checked... I'll need to engage with this more at some point but it's  
> not strongly luring me out of my niche yet.

clang's libc++ apparently still requires libsupc++ at least on linux; the equivalent library for clang runs on OSX/*BSD, but is experimental on Linux.

All the alternate compilers currently require gnu binutils.
Clang/LLVM have no plans to address this that I can see.
pcc is the closest to not doing so, since it can use yasm as assembler, but this is pretty limited in application and requires a linker.

elftoolchain is not really useful yet, though there's an ar implementation and some code towards ld.
Somewhere else I ran across a linker based on llvm. I wish I could remember its name...
Hmm...lld.llvm.org claims that "In the same way that the MC layer of LLVM has removed clang?s reliance on the system assembler tool, the lld project will remove clang?s reliance on the system linker tool."
I guess that means they're finally working on getting rid of the binutils dependency.
Ah, that's what I wanted:
http://code.google.com/p/mclinker/
1/8 the size of binutils, "designed for on-device compiling" (specifically mentions low memory use), supports arm/mips/x86


> Rob

-- 
Isaac Dunham <idunham at lavabit.com>


 1358185812.0

From rob at landley.net  Tue Jan 15 00:03:09 2013
From: rob at landley.net (Rob Landley)
Date: Mon, 14 Jan 2013 18:03:09 -0600
Subject: [Aboriginal] Aboriginal Digest, Vol 24, Issue 3
In-Reply-To: <20130114095012.60604cb9.idunham@lavabit.com> (from
	idunham@lavabit.com on Mon Jan 14 11:50:12 2013)
Message-ID: <1358208189.32505.22@driftwood>

On 01/14/2013 11:50:12 AM, Isaac Dunham wrote:
> On Mon, 14 Jan 2013 07:27:17 -0600
> Rob Landley <rob at landley.net> wrote:
> > If I _can_ build a 64-bit only environment, I'd like to do that.  
> That's
> > how the x86-64 target works, for example. (You can add 32 bit  
> libraries
> > after the fact, by building them  natively on target.)
> >
> > Last I checked uClibc didn't support it, but musl might someday.
> 
> "it" == building only 64-bit libs when targeting 64-bit arches?

"it" == sparc64, but possibly I was thinking ppc64 or s390.

To support something in aboriginal I need toolchain, libc, qemu, and  
kernel support. I need to get the kernel and qemu to agree on a board  
emulation with the appropriate I/O devices, and I need userspace, libc,  
and kernel to agree on a system call interface with a consistent  
floating point implementation.

> If so, that's all that musl supports; there is no automated "we think  
> you ought to
> support another ABI, so we're building it also."

That's not libc's job, if you wanted to support both you'd build it  
twice with two different compiler output modes and then ahve parallel  
library search paths ala /lib32 and /lib64 and that's what I don't do.  
(I just do the lib64 and then if you want to add lib32 natively on  
target you can do so after the fact. See the x86_64 image as an  
example, it's got kernel support for 32 bit syscalls but not a 32 bit  
library or toolchain. So you can drop static 32 bit binaries on there  
and run them if you like, but if you need a 32 bit chroot you need to  
supply it yourself. I have one in i686 and you can extract the i686  
tarball on there, but integrating them is left as an exercise for the  
user.)


> > > clang seems to be making headway, but pcc seems to be at the  
> "well,
> > > it's more
> > > active than tcc..." level. It can bootstrap at least OpenBSD,  
> though,
> >
> > Clang needs C++ on the host in order to build (but only recently  
> wrote
> > its own C++ standard library), didn't have its own binutils last I
> > checked... I'll need to engage with this more at some point but it's
> > not strongly luring me out of my niche yet.
> 
> clang's libc++ apparently still requires libsupc++ at least on linux;  
> the
> equivalent library for clang runs on OSX/*BSD, but is experimental on  
> Linux.

There are reasons clang is still on my todo list. Clean  
self-bootstrapping really isn't high on their todo list. (Building a  
linux kernel is still one of those crotchety not-quite-supported things  
of the "somebody says they got it to sort of work once" variety.)

> All the alternate compilers currently require gnu binutils.

Tinycc doesn't. Alas, I need a spare year on a desert island to do qcc.

> Clang/LLVM have no plans to address this that I can see.
> pcc is the closest to not doing so, since it can use yasm as  
> assembler, but this is
> pretty limited in application and requires a linker.

It also requires lex and yacc to bootstrap, last I tried it.

> elftoolchain is not really useful yet, though there's an ar  
> implementation and some
> code towards ld.

Dunno that one.

> Somewhere else I ran across a linker based on llvm. I wish I could  
> remember its
> name...

I need to read the GOLD development blog entries. (I've read something  
like the first 3, then bookmarked it...)

> Hmm...lld.llvm.org claims that "In the same way that the MC layer of  
> LLVM has removed
> clang?s reliance on the system assembler tool, the lld project will  
> remove clang?s
> reliance on the system linker tool."

Apple wants to brick up GPL's corpse in the basement wall because  
GPLv3. I can't blame 'em.

> I guess that means they're finally working on getting rid of the  
> binutils dependency.

It's a todo item. We all have our lists...

> Ah, that's what I wanted:
> http://code.google.com/p/mclinker/
> 1/8 the size of binutils, "designed for on-device compiling"  
> (specifically mentions
> low memory use), supports arm/mips/x86

Cool, but binutils contains a half-dozen things and an assembler is a  
fairly important one of those.

Also, the reason my qcc idea glued QEMU's Tiny Code Generator to the  
tinycc front-end was to leverage the target support the qemu guys do.  
They've got sh4, sparc, s390, cris, and so on. Large existing  
development team, leveraging their work would be really nice.

Rob
 1358208189.0

From rob at landley.net  Mon Jan 28 12:42:06 2013
From: rob at landley.net (Rob Landley)
Date: Mon, 28 Jan 2013 06:42:06 -0600
Subject: [Aboriginal] Status.
Message-ID: <1359376926.32505.51@driftwood>

I'm aware the new toybox cp broke root-filesystem.sh because the "yes n  
| cp -i" bit isn't working right, so native builds don't work right  
now. I didn't get a chance to fix it this weekend because I moved into  
my new apartment in minnesota (6 month contract) but possibly this  
evening.

I'm pondering just checking in the perl removal patch update, which  
requires a 3.8-rc to build. Since I removed the alt- infrastructure  
this is trivial to do in local development branches via a fork or just  
having two checkouts, but when I want to refer to stuff in the main  
repo it gets weird. (Not as convenient internet access here, harder to  
shuffle stuff from machine to machine.) In general, sitting on a change  
waiting for an upstream dependency package to release its final version  
is... fiddly.

In general I'm on course to cut a release shortly after the next kernel  
drops. I started testing this time during the -rc2 timeframe and I  
think I've got most of the obvious stuff out of the way. There's a new  
busybox release I should grab, that needs testing, but shouldn't break  
too much and is reasonable to bisect if it does...

Rob
 1359376926.0