sed breaks when statically linked against glibc?

Rob Landley rob at landley.net
Tue Oct 27 18:41:45 UTC 2009


On Tuesday 27 October 2009 03:16:17 Denys Vlasenko wrote:
> On Mon, Oct 26, 2009 at 11:33 PM, Rob Landley <rob at landley.net> wrote:
> > It looks like this old bug has resurfaced yet again:
> >
> > http://lists.busybox.net/pipermail/busybox/2006-December/025611.html
> > http://bugs.gentoo.org/show_bug.cgi?id=234547
> >
> > On xubuntu 9.04, building busybox more or less defconfig, the following
> > sed invocation (which turns a .config file into a config.h file) works
> > fine, and converts the attached .config into the attached config.h.
> >
> > # This long and roundabout sed invocation is to make old versions happy.
> > # New ones have '\n' so can replace one line with two without all the
> > branches # and tedious mucking about with hold space.
> >
> > sed -n \
> >  -e 's/^# CONFIG_\(.*\) is not set.*/\1/' \
> >  -e 't notset' \
> >  -e 's/^CONFIG_\(.*\)=y.*/\1/' \
> >  -e 't isset' \
> >  -e 's/^CONFIG_\([^=]*\)=\(.*\)/#define CFG_\1 \2/p' \
> >  -e 'd' \
> >  -e ':notset' \
> >  -e 'h' \
> >  -e 's/.*/#define CFG_& 0/p' \
> >  -e 'g' \
> >  -e 's/.*/#define USE_&(...)/p' \
> >  -e 'd' \
> >  -e ':isset' \
> >  -e 'h' \
> >  -e 's/.*/#define CFG_& 1/p' \
> >  -e 'g' \
> >  -e 's/.*/#define USE_&(...) __VA_ARGS__/p' \
> >  .config > generated/config.h
> >
> > But when busybox is built with LDFLAGS="--static", busybox sed produces
> > no output (and thus an empty config.h.)
> >
> > I thought busybox had some workaround code for this?  Calling
> > fflush(stdout) via atexit() or something similar?
>
> It's likely a known problem with glibc+static linking.
> Try building static by CONFIG_STATIC=y instead of just adding
> a switch via LDFLAGS, scripts/trylink has code to detect that:

My build script has a "build all packages static" control, so it's trying to 
do this at the toolchain level.  I added a different special case to not try to 
build busybox static on the host, since the toolchain is unknown.

> # Static linking against glibc produces buggy executables
> # (glibc does not cope well with ld --gc-sections).
> # See sources.redhat.com/bugzilla/show_bug.cgi?id=3400
...
>------- Additional Comment #1 From Ulrich Drepper  2006-10-19 20:20  [reply]
> -------
>
>You simply cannot use that option.  Period.  Static linking is not really
>supported.  I'm not closing the bug outright so that somebody with interest
> can think of a clean and non-intrusive way to handle this.  But I sure as
> hell won't spend a second thinking about static linking.

Ah, good old Ulrich.  I remember now.

How about a config options GLIBC_STATIC_WORKAROUND that adds an atexit() call 
to the busybox applet multiplexer?  I.E. adding this to libbb:

void xflush(void)
{
	fflush(NULL);
}

(Which seems potentially useful from a bunch of places, saving 4 bytes/call 
for flushes since there's seldom any case where we _don't_ want to flush all 
pending ANSI output streams.)

And then somewhere in busybox_main (wherever it's got to, somewhere under 
libbb these days I think):

  if (ENABLE_GLIBC_STATIC_WORKAROUND) atexit(xflush);

The ENABLE_GLIBC_STATIC_WORKAROUND I'm not sure about, it saves maybe 10 bytes 
but it's 10 bytes in the applet launch path.  Possibly this is a reason to use 
the #ifdef salad to check for uClibc and dietlibc and newlib and not do it 
there since you can't just check for glibc because they all _pretend_ to be 
glibc which is just _sad_.  Sigh...

Anyway, does that look worth a try?

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds


More information about the busybox mailing list