[Clfs-dev] Embedded Pull Request

[Andrew Bradford]

Rob,

On Fri, Jul 26, 2013, at 11:03 PM, Rob Landley wrote:
> On 07/24/2013 01:44:35 PM, Andrew Bradford wrote:
> > OK, well, don't pull this, yet. I forgot to change the patch names to
> > account for the roll back in uClibc version.
> > 
> > I'll fix that and resend.
> 
> I note that my aboriginal linux project is using the last (ever?)  
> release of uClibc just fine, and natively building linux from scratch  
> under it for arm, mips, powerpc, sparc, x86, and x86_64. (In theory sh4  
> should work too but qemu's board emulation only provides 64 megs of ram  
> and gcc barfs trying to build much more than "hello world" with that.  
> I'm poking at getting alpha working.)

I've recently found your aboriginal Linux project and hope to get more
familiar with it.  Looks like a very good resource.

I rolled back to an older version of uClibc due to our configs patch
leaving a lot of questions for the user when doing a 'make oldconfig' on
the newest uClibc release.  I'm working on migrating to the newest
uClibc, but in stages rather than all at once so that I can understand
what new config options are present and craft a sane config patch.

> If you have any interst in the patches, config, or build invocations  
> that made that work, they're all at http://landley.net/aboriginal

I'll take a look.  My biggest beef with uClibc is just that keeping a
patch up to date for uClibc configuration has been annoying and time
consuming.  I'm lazy.  My assumption is that the uClibc defconfig is not
a sane configuration most of the time, but that's only based off of a
small amount of investigation, I need to do more.  My desire is to use a
libc that doesn't involve a thousand config variables or to use uClibc
in a way that can leverage the defconfig sanely.

> That said, I'm working on migrating the project to musl over the next  
> couple releases: uClibc development's been moribund for years, musl's  
> git repository started in Feb 2011 and it's approaching 1.0 already;  
> not a tough call. The downside is I've got a dozen or so targets  
> working under uClibc and musl supports something like 4 at the moment,  
> but klibc has code under a compatible license musl could bootstrap the  
> others with, so it shouldn't take too long. (Including stuff like s390  
> that uClibc never did support, but qemu _does_...)

We're also evaluating musl for the clfs-embedded book.  I've recently
subscribed to the musl ml and your toybox ml.  Both projects look very
interesting to me from a KISS standpoint which I think is a good way for
clfs-embedded to go.

Thanks,
Andrew