sed breaks when statically linked against glibc?

Denys Vlasenko vda.linux at googlemail.com
Wed Oct 28 13:40:02 UTC 2009


On Tue, Oct 27, 2009 at 7:41 PM, Rob Landley <rob at landley.net> wrote:
> 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.

He didn't close the bug, and didn't use F words. A few centuries more
and he may become tolerable.

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

Well, if you are ok with switching on this option then you are equally ok
with switching on CONFIG_STATIC, which already exists and makes
this problem go away.

> 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);

Unfortunately, (1) we use _exit() a lot, and
(2) atexit machinery itself may similarly be affected by -static

I can throw a fflush(NULL) into main() _after_ we call <applet>_main(),
if there is no way for you to force CONFIG_STATIC on.

--
vda


More information about the busybox mailing list