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 _______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
