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