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