here is sample case: busybox 1.23.2: $touch 1 2 3 4 5; find ./; echo "---"; find ./ |sort ./ ./5 ./4 ./3 ./2 ./1 --- ./ ./1 ./2 ./3 ./4 ./5 busybox 1.24.1: $touch 1 2 3 4 5; find ./; echo "---"; find ./ |sort ./ ./5 ./4 ./3 ./2 ./1 ---
Can't reproduce. Please reopen and attach your .config
Created attachment 6271 [details] config to reproduce bug Config file is generated by 'make oldconfig' with majority of questions set to "no" from working 1.23.2 config.
I can't reproduce it even with your config. You will have to look deeper on the system which exhibits the bug, or try reproducing it under qemu. See https://busybox.net/FAQ.html#emu
Here is qemu image of buggy busybox: http://rghost.ru/6MY9rYpFF# (external link due to file size limit in bugzilla) I got this image from http://wiki.qemu.org/Testing and added busybox and busybox_unstripped, both configs (working 1.23.2 and buggy 1.24.1), and test case. Image can be mounted with -o loop to transfer files run command: #qemu-system-i386 -m 256 -hda ./linux-0.2.img testcase: cd /busybox-test ./testcase.sh
Above link is compessed image (via xz), if you need uncompressed image (about 20mb), please use this link: http://rghost.ru/7KbZxGqMP
I noticed that this bug is somehow releated to glibc/and/or gcc. On glibc 2.11.3 + gcc 4.4.4 it can be reproduced, but when I switch to glibc 2.22 + gcc 4.9.3, it's gone.
Reproduced in qemu. This looks like a reappearance of an old glibc bug where stdout wasn't flushed on exit, because glibc uses some linker magic to achieve that and --gc-sections was breaking it. The symptom was that "CMD" which outputs a lew lines of text was working, but "CMD | cat" was printing nothing. scripts/trylink has a workaround: # 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 # Note that glibc is unsuitable for static linking anyway. # We are removing -Wl,--gc-sections from link command line. GC_SECTIONS="-Wl,--gc-sections" if (. ./.config && test x"$CONFIG_STATIC" = x"y") then if check_libc_is_glibc; then echo "Static linking against glibc, can't use --gc-sections" GC_SECTIONS="" fi fi (1) Do you see the "Static linking against glibc, can't use --gc-sections" message when you build the buggy executable? (2) If you switch CONFIG_STATIC=y to off, change nothing else, and rebuild bbox, does resulting binary still show the bug? If both answers are "yes", then glibc is now broken wrt static linking in a different way than before...
1. With busybox 1.23.2 (not buggy) there is no such message. With busybox 1.24.1 (buggy) i see that message. I noticed some inconsistence in trylink between git and release (http://busybox.net/downloads/busybox-1.24.1.tar.bz2) image: --- ./trylink.1241 2015-10-24 07:27:41.000000000 +0700 +++ ./trylink.git 2016-03-17 15:07:37.000000000 +0600 @@ -54,7 +54,7 @@ # "eval" may be needed if CFLAGS can contain # '... -D"BB_VER=KBUILD_STR(1.N.M)" ...' # and we need shell to process quotes! - $CC $CFLAGS $1 "$tempname".c -o "$tempname" >/dev/null 2>&1 + $CC $CFLAGS $LDFLAGS $1 "$tempname".c -o "$tempname" >/dev/null 2>&1 r=$? rm -f "$tempname" "$tempname".c "$tempname".o return $r @@ -111,7 +111,7 @@ if (. ./.config && test x"$CONFIG_STATIC" = x"y") then if check_libc_is_glibc; then echo "Static linking against glibc, can't use --gc-sections" -# GC_SECTIONS="" + GC_SECTIONS="" fi fi # The --gc-sections option is not supported by older versions of ld I found LDFLAGS commit: https://git.busybox.net/busybox/commit/?id=77e2bde6a50f0f6b9b3c9983c86e661a9872b5f6 But i cannot find, which commit comments/uncomments GC_SECTIONS in trylink between 1.23.2 and 1.24.1: https://git.busybox.net/busybox/log/scripts/trylink With fixed trylink (uncommenting GC_SECTIONS="") bug is gone on busybox 1.24.1 2. dynamic linking also fixes bug.
(In reply to alex hauras from comment #8) > echo "Static linking against glibc, can't use --gc-sections" > -# GC_SECTIONS="" > + GC_SECTIONS="" Oh no. Please try http://busybox.net/downloads/busybox-1.24.2.tar.bz2
1.24.2 works without bug, thank you!