[Clfs-dev] Embedded Pull Request

[Rob Landley]

On 07/29/2013 12:27:13 PM, Andrew Bradford wrote:
> 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.

Understood. I put a lot of _effort_ into getting newer versions of  
uClibc to work, which is why I pointed you at my setup so you could  
leverage it.

I have one config that's mostly the same for all targets. It's the set  
of options I needed to build Linux From Scratch natively under the  
resulting system, so it's got a lot of things like gnu regex instead of  
simpler regex. (I'll have to fight that battle all over again with  
musl...)

I don't bother with what's in git. When they have a release, I care. If  
it's not in a release and not winding up in a release in the forseeable  
future, I don't care. And unfortunately, uClibc git is in such horrible  
state that you can't bisect anything because none of the intermediate  
versions compile, let alone work, so... their repository is useless to  
me.

> > 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 uClibc config is a baseconfig plus target specific snippets, using  
the "miniconfig" technique. It started with a read through the options  
many moons ago, and since then is experimentally derived based on what  
various packages needed to build.

Basically I take this:

   http://landley.net/hg/aboriginal/file/1616/sources/baseconfig-uClibc

And glue the UCLIBC_CONFIGURE chunks of these files to the start of  
them:

   http://landley.net/hg/aboriginal/file/1616/sources/targets

And then run it through:

   make allnoconfig KCONFIG_ALLCONFIG=filename

And that's my .config.

> 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.

In theory, that would be musl. I'm following that project very closely  
and working on redoing my infrastructure to use it.

(My build uses a much modified version of the old uClibc wrapper to  
rewrite each gcc command line to start with --nostdinc --nostdlib and  
then explicitly add back everything it needs. I gave up trying to fix  
the gcc path logic and use something to take pathing decisions out of  
gcc's hands entirely.)

> > 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. Musl is noticeably closer to a 1.0 release.

Aboriginal Linux starts with a sort of "airlock step" (host-tools.sh)  
where it builds busybox and toybox and a couple other things like  
mksquashfs, and then changes the $PATH to point to just that new  
directory, so the rest of the build is done using those tools. This is  
a little bit like chapter 5 of LFS, but without the chroot (because  
that would require root access and my build runs entirely as a normal  
user).

The host-tools stuff means I actually have some portability (should  
work the same on ubuntu and gentoo and fedora and such), and to derive  
what should go in there I have a command recording wrapper  
(http://landley.net/aboriginal/FAQ.html#debug_logging) that gives me a  
list of every single command line run out of the $PATH during the  
build, and then another script gives me a list of commands and how many  
times each one got run.

This let me trim the busybox config down from "defconfig" to a specific  
config:

   http://landley.net/hg/aboriginal/file/1616/sources/baseconfig-busybox

And then I started replacing those commands with toybox. (Everything  
after the toybox comment, line 143 at the moment, is stuff busybox used  
to do that toybox now does instead; they're still there so I can test  
build with busybox if I want to, but the default build filters 'em out  
with a sed invocation.) This means busybox is still used for:

   ash awk bunzip2 bzip2 cpio dd diff egrep expr fdisk fgrep find ftpd
   ftpget ftpput grep gunzip gzip install less lspci man mount pgrep
   ping pkill ps route sed sh sha512sum tar test tr umount unxz vi wget
   xzcat zcat

So toybox has a way to go before it can replace the rest of busybox in  
the aboriginal build. But I'm working on it. :)

Musl already builds lots of packages under sabotage, so they've found  
the most obvious stuff already. (They patch a lot of those packages,  
though. Sabotage is the main collection point for them. Someday,  
googling for "musl sabotage" might give the current repository instead  
of the old abandoned one. Until then, the link's on the musl wiki under  
distros.)

Rob