[BusyBox] busybox, sed, and zlib's configure script

Rob Landley rob at landley.net
Mon Sep 22 08:16:31 UTC 2003


On Monday 15 September 2003 22:48, Glenn McGrath wrote:
> With all my "fixes" in the last couple of days i had introduces a pretty
> fundamental error, which ive now fixed.
>
> I just did some more testing and it is getting further in lots of cases,
> but im having problems with my toolchain, wierd compiler errors.
>
> It is correctly parsing GNU make's configure script again, and the sed
> script from binutils Rob sent in is working, but the script in e2fsprogs
> isnt.
>
> Im going to step back a bit now, give Rob some elbow room ;)

Time for a random status update:

I got distracted this weekend by a bug in the 2.6.0-test5-mm2 kernel, which 
caused tar (not busybox tar, gnu tar) to hang in D state during a run of my 
build script.  Eventually I got a debug trace posted to linux-kernel, and 
presumably Andrew Morton's looking at it, so I backed up to -test4 and 
resumed banging.  On the bright side, -mm2 made my USB scanner work. :)

The CVS version of busybox configures and builds binutils, but the next stage 
that actually tries to use those new binutils segfaults as soon is tries to 
run ld.  (Running ld manually segfaults immediately too.)

I'm not sure if the problem is busybox producing an invalid config or some bug 
in uclibc coming out of the woodwork.  I'm going to do a static build of ld 
with the straight gnu toolchain (glibc, gnu sed, etc.) and compare the config 
to see if that reveals anything obvious, then re-introduce uclibc and busybox 
separately to try to narrow this down.

But alas, it is monday again, and as always I'll be buried up to my eyeballs 
in classwork until wednesday...

Oh, one more thing: in order to get binutils to configure properly, sed needs 
the newline matching hack enabled.  What exactly IS the warning regarding 
that?  (Some kind of standards violation?  The meat of the hack seems to 
replace \n with \\n, but there's some other ifdefs I didnt'have time to trace 
throught due to playing with experimental kernels.)

What's a test case that would fail because of this hack being enabled?

Rob



More information about the busybox mailing list