[uClibc] Re: Again some buildroot patches

Matthias Kilian kili at outback.escape.de
Mon Jan 12 21:48:07 UTC 2004


[Slighly ot, since more busybox than uClibc stuff]

On Sun, Jan 11, 2004 at 11:15:27PM -0600, Rob Landley wrote:
[ed vs. sed, completely ot]
> sed -i for in-place editing.

I'm running out of arguments, and I'm deeply depressed ;-)

Wait! It is *editor*, not *seditor*.

And, more important, you can use ed as an interactive editor to impress
and confuse your customers. For example if you sit down at the customer's
server console and just change an IP number in the named configuration. If
you use vi or emacs, the customer will think "Shit! I pay that guy
for just changing that f*ck*ng IP number." He will fell very bad about
this. But if you use ed(1), with a little bit of luck, the customer won't
understand what you're doing. You'll be worth what the customer is charged
for, since you must be a real *nix guru. [Note that this example isn't
mine. Fortunately, I'm not a system administrator, so I'm free to use vi.]

> > I'll try to rebuild everything and check for differences with an updated
> > busybox today or tomorrow.
> 
> Cool.  I look forward to hearing how it works for you...

So now for the interesting stuff:

It kind of works, with some problems. Just for fun, I used buildroot
but left out those two lines containing coreutils, fileutils, bash etc.

And for the *real* fun, I booted the resulting buildroot in an 2.4.24 UML,
and started bootstrapping GNU make-3.80: I'd to slightly edit build.sh
after ./configure, but that's a bug of GNU make, I think.

For building perl (5.8.2), I first had to compile patch-2.5.4 for
applying Manuel's patches, since the version of patch included within
busybox did fail:

$ patch -p1 < ../perl.patch-filedes
patching file perlio.c
patch: Bad src file
[After that, the "patched" perlio.c had size 0]

I also had to implemen comm(1), which is not included in busybox. Rob,
I'll send you a separate mail with a patch adding comm(1) to busybox.

Finally, I got a (nearly) busybox-only uclibc-root with a working gmake,
a working patch and a slightly broken perl.

Compared with a uclibc-root containing all the stuff from ftp.gnu.org
(and alpha.gnu.org) rather than only busybox, many of perl's testcases
failed or just looped forever (and thus had to be killed).

However, it *is* possible to build perl-5.8.2 within a busybox-based
uclibc-root and within a fully-featured uclibc-root (with bash, coreutils,
...). You just have to use the two small patches Manuel recently sent.

Noteworthy differences between busybox-only (called bb from now on)
and full uclibc-root (called gnu from now on):

- using bb, the hostname is set to "uclibc" (as intended by the
  skeleton of buildroot), using gnu, the hostname isn't set.
- for some (yet unknown) reason, with bb the perl Configure.sh fails
  to get the correct signal list (which causes many test case failures).
  Instead of finding all 68 signals (as the gnu version does), it just
  finds one signal called "ZERO".
- the gnu buildroot found /proc/self/exe, while the bb buildroot didn't.

And there were great performance differences between bb and gnu, at
least within the UML I played with. The bb-root used significantly more
system cpu time within the host system than the gnu-root used. I've no
idea wether that's an uClibc, busybox or UML issue.

To summarize: I think that a minimal uClibc-root not only is lot of
fun to start with, but also is great for testing uClibc and/or busybox
completelness/correctness, at least for platforms that allow for excessive
compilation (no one wants to build perl within a toaster).

Starting from scratch with a minimalistic uClibc-root will probably help
discovering lots of bugs within uClibc and/or busybox.

Ciao,
	Kili

ps: next on my TODO-List:
1. use tcc and/or lcc instead of gcc.
2. have a lunch at Milliways.




More information about the uClibc mailing list