[PATCH] misc size-shrinkage; merges

Rob Landley rob at landley.net
Tue Aug 29 20:22:03 UTC 2006


On Monday 28 August 2006 8:07 pm, Bernhard Fischer wrote:
> On Tue, Aug 29, 2006 at 01:57:25AM +0200, Bernhard Fischer wrote:
> >On Sun, Aug 20, 2006 at 04:48:06PM -0400, Rob Landley wrote:
> >>On Sunday 20 August 2006 8:31 am, Bernhard Fischer wrote:
> >>> On Fri, Aug 18, 2006 at 11:49:01PM -0400, Rob Landley wrote:
> >>> >On Friday 18 August 2006 11:53 am, Bernhard Fischer wrote:
> >>> >> Hello,
> >>> >> 
> >>> >> Just a heads up..
> >>> >> I plan to push the below patchset (split-up, of course) into my
> >>> >
> >>> >Yes please.  (Reviewing 4000 lines at once ain't fun.)
> >>> >
> >>> >> 'busybox_scratch' branch soonish, then merge that branch back into
> >>> >> trunk.
> >
> >I merged most of the lingering changes off the busybox_scratch branch
> >back into trunk in r16009.
> >
> >A few notes.
> >
> >I mean to merge (parts of) trunk back into my branch.
> >There are, however, severe defects on current trunk;
> >
> >1) trunk is b0rk
> >This config (off IRC, tell me if it went offline when you happen to read
> >this) fails basic tests. http://rafb.net/paste/results/XtWePX12.html
> 
> Saved here: http://busybox.net/~aldot/bb/busybox.config.Breeze

I copied that .config into my directory, did a make clean, and a make 
oldconfig.  The oldconfig prompted me for a couple screens worth of things, I 
don't know why.

Ok...  Odd.

I've simplified it to:

echo "a=b" | ./busybox cut -d'=' -f2 | cat

Which works when you don't have the | cat on the end, but doesn't when you do.  
Why is cut caring about whether or not its output has been redirected?  And 
why is this configuration dependent?  Well, it's only a 332 line applet, 
let's see...

Something screwing up printf, and it's doing so fairly early in the process.  
It's not closing fd 1, if I write(1,"blah",4) it goes out, but printf() does 
not.  Hmmm.  Well, if it's config dependent let's see what the config 
difference is...

You've switched off verbose usage, the installer, locale support, suid, you're 
building statically, you yanked susv2...  Locale, suid, and static are the 
three biggies, let's try defconfig with those...  Nope, that's not 
reproducing it.  Static linking?

Wow.  It's _static_linking_ that's doing it.  Ok, that's just ODD.  Lemme try 
this with my uClibc cross compiler...

And the problem does not reproduce with uClibc!

You say one of the commits since you forked your tree produced this?  When did 
you fork your tree?

> >Failing use-case: echo `echo a=b | cut -d'=' -f2`
> 
> Note that trunk r16008 (i.e. before i checked in my cleanup/shrinkage)
> to cut does also fail the above case. I did not look what broke this,
> though. HTH

Possibly upgrading glibc?

I can reproduce this, but it's _weeeeeird_.  I'll see if I can track down what 
exactly we're doing that's perturbing statically linked glibc (this problem 
isn't occurring with a statically linked "hello world"), but I've spent about 
as much time tracking it down as I've got right now.  Maybe this evening...

It might be something we're doing with our linker flags, but alas the current 
build system is too brain-damaged to extract them easily:

landley at driftwood:~/busybox/busybox$ rm busybox
landley at driftwood:~/busybox/busybox$ make V=1
make -C /home/landley/busybox/busybox \
        top_srcdir=/home/landley/busybox/busybox \
        top_builddir=/home/landley/busybox/busybox \
        BUILD_SRC=/home/landley/busybox/busybox \
        -f /home/landley/busybox/busybox/Makefile _all
cp busybox_unstripped busybox
strip -s --remove-section=.note --remove-section=.comment busybox

That's just too useful for words.

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list