[SOLVED] Static building of busybox fails, after update gcc/glibc?

CodeAsm · 2020-02-13 16:30:50

Hi hello,
Im not a big expert with libraries or gcc but after 2 days trying (did other work between) I feel like im stuck.
I tried googling and duckduckgo for solutions but maybe ive overlooked something to try or dint read a new-/update-memo.

[update] I followed eschwartz advice to take a look at the official community/busybox package, musl is a nice alternative to glibc and looking at their config and how to build a static busybox worked. Ill addapt my own project but I consider my problem solved based on my question. I now have a staticly build busybox again, by "just" using musl (and the community/busybox config for now).
original question bellow.

I cannot seem to succesfully build busybox 1.31.1 (or older) as a static program. its based on instructions found here: http://mgalgs.github.io/2015/05/16/how- … ition.html but Ive also tried it basicly with this:

tar xjf busybox-1.31.1.tar.bz2
cd busybox-1.31.1.tar.bz2
mkdir -pv ../obj/busybox-x86
make O=../obj/busybox-x86 defconfig

The following can also be switched on by means of make menuconfig and selecting the static build of busybox

 sed -i '/# CONFIG_STATIC is not set/c\CONFIG_STATIC=y' ../obj/busybox-x86/.config

then we do

cd ../obj/busybox-x86
make -j$(nproc)

This worked fine for a long time, ive been building this for the past year atleast and with regular arch updates in between.
few days ago, I think Februari 11 2020, ive updated arch using the regular update procedure (I use pikaur, with Syu).
And all of a sudden I recieve this (compiling stuff ontop redacted)

  CC      libbb/xregcomp.o
  AR      libbb/lib.a
  LINK    busybox_unstripped
Static linking against glibc, can't use --gc-sections
Trying libraries: crypt m resolv
Failed: -Wl,--start-group  -lcrypt -lm -lresolv  -Wl,--end-group
Output of:
gcc -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wno-format-security -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-builtin-printf -Os -static -o busybox_unstripped -Wl,--sort-common -Wl,--sort-section,alignment -Wl,--start-group applets/built-in.o archival/lib.a archival/libarchive/lib.a console-tools/lib.a coreutils/lib.a coreutils/libcoreutils/lib.a debianutils/lib.a klibc-utils/lib.a e2fsprogs/lib.a editors/lib.a findutils/lib.a init/lib.a libbb/lib.a libpwdgrp/lib.a loginutils/lib.a mailutils/lib.a miscutils/lib.a modutils/lib.a networking/lib.a networking/libiproute/lib.a networking/udhcp/lib.a printutils/lib.a procps/lib.a runit/lib.a selinux/lib.a shell/lib.a sysklogd/lib.a util-linux/lib.a util-linux/volume_id/lib.a archival/built-in.o archival/libarchive/built-in.o console-tools/built-in.o coreutils/built-in.o coreutils/libcoreutils/built-in.o debianutils/built-in.o klibc-utils/built-in.o e2fsprogs/built-in.o editors/built-in.o findutils/built-in.o init/built-in.o libbb/built-in.o libpwdgrp/built-in.o loginutils/built-in.o mailutils/built-in.o miscutils/built-in.o modutils/built-in.o networking/built-in.o networking/libiproute/built-in.o networking/udhcp/built-in.o printutils/built-in.o procps/built-in.o runit/built-in.o selinux/built-in.o shell/built-in.o sysklogd/built-in.o util-linux/built-in.o util-linux/volume_id/built-in.o -Wl,--end-group -Wl,--start-group -lcrypt -lm -lresolv -Wl,--end-group
==========
/usr/bin/ld: libbb/lib.a(inet_common.o): in function `INET6_resolve':
inet_common.c:(.text.INET6_resolve+0x46): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: coreutils/lib.a(mktemp.o): in function `mktemp_main':
mktemp.c:(.text.mktemp_main+0x94): warning: the use of `mktemp' is dangerous, better use `mkstemp' or `mkdtemp'
/usr/bin/ld: networking/lib.a(ipcalc.o): in function `ipcalc_main':
ipcalc.c:(.text.ipcalc_main+0x214): warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: libbb/lib.a(inet_common.o): in function `INET_resolve':
inet_common.c:(.text.INET_resolve+0x49): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: networking/lib.a(inetd.o): in function `reread_config_file':
inetd.c:(.text.reread_config_file+0x249): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: networking/lib.a(netstat.o): in function `ip_port_str':
netstat.c:(.text.ip_port_str+0x50): warning: Using 'getservbyport' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: util-linux/lib.a(rdate.o): in function `rdate_main':
rdate.c:(.text.rdate_main+0xf8): undefined reference to `stime'
/usr/bin/ld: coreutils/lib.a(date.o): in function `date_main':
date.c:(.text.date_main+0x22d): undefined reference to `stime'
collect2: error: ld returned 1 exit status
Note: if build needs additional libraries, put them in CONFIG_EXTRA_LDLIBS.
Example: CONFIG_EXTRA_LDLIBS="pthread dl tirpc audit pam"
make[2]: *** [/home/codeasm/Projects/Emulation/Linux/bin/busybox-1.31.1/Makefile:718: busybox_unstripped] Error 1
make[1]: *** [Makefile:112: _all] Error 2
make: *** [Makefile:14: all] Error 2

At first I was afraid I changed something in my build script and tested alott of diferent things. using a straightforward helloworld as a init for my qemu worked fine. but busybox seems to now not compile. Ive also doing some testing in Linux from scratch, and Ive tested inside a chroot envirement in there to build busybox there, wich worked fine. when I transfer the build result and start making a initramfs with those files it works fine.

Im guessing
Trying libraries: crypt m resolv
Failed: -Wl,--start-group -lcrypt -lm -lresolv -Wl,--end-group hints at a change of my system wich is now nolonger providing libs crypt, m and resolv as static or something.

output for my gcc:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-pkgversion='Arch Linux 9.2.1+20200130-2' --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared --enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib --disable-werror --enable-checking=release --enable-default-pie --enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.1 20200130 (Arch Linux 9.2.1+20200130-2)

while LFS has (this is from within the chroot envirement):

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-languages=c,c++ --disable-multilib --disable-bootstrap --with-system-zlib
Thread model: posix
gcc version 9.2.0 (GCC)

While im not sure, there might be a symlink broken or missing files?

$ ls /lib*/libm.* /lib*/libresolv* /lib*/libcrypt* -lah
-rwxr-xr-x 1 root root  43K Feb  2 14:11 /lib/libcrypt-2.31.so
-rw-r--r-- 1 root root  55K Feb  2 14:11 /lib/libcrypt.a
lrwxrwxrwx 1 root root   13 Feb  2 14:11 /lib/libcrypt.so -> libcrypt.so.1
lrwxrwxrwx 1 root root   16 Feb  2 14:11 /lib/libcrypt.so.1 -> libcrypt-2.31.so
lrwxrwxrwx 1 root root   16 Nov 13 17:09 /lib/libcrypto.so -> libcrypto.so.1.1
-r-xr-xr-x 1 root root 2.7M Jan 25 11:36 /lib/libcrypto.so.1.0.0
-rwxr-xr-x 1 root root 2.8M Nov 13 17:09 /lib/libcrypto.so.1.1
-rw-r--r-- 1 root root   98 Feb  2 14:11 /lib/libm.a
-rw-r--r-- 1 root root  114 Feb  2 14:11 /lib/libm.so
lrwxrwxrwx 1 root root   12 Feb  2 14:11 /lib/libm.so.6 -> libm-2.31.so
-rwxr-xr-x 1 root root  87K Feb  2 14:11 /lib/libresolv-2.31.so
-rw-r--r-- 1 root root 126K Feb  2 14:11 /lib/libresolv.a
lrwxrwxrwx 1 root root   14 Feb  2 14:11 /lib/libresolv.so -> libresolv.so.2
lrwxrwxrwx 1 root root   17 Feb  2 14:11 /lib/libresolv.so.2 -> libresolv-2.31.so
-rwxr-xr-x 1 root root  43K Feb  2 14:11 /lib64/libcrypt-2.31.so
-rw-r--r-- 1 root root  55K Feb  2 14:11 /lib64/libcrypt.a
lrwxrwxrwx 1 root root   13 Feb  2 14:11 /lib64/libcrypt.so -> libcrypt.so.1
lrwxrwxrwx 1 root root   16 Feb  2 14:11 /lib64/libcrypt.so.1 -> libcrypt-2.31.so
-rw-r--r-- 1 root root   98 Feb  2 14:11 /lib64/libm.a
-rw-r--r-- 1 root root  114 Feb  2 14:11 /lib64/libm.so
lrwxrwxrwx 1 root root   12 Feb  2 14:11 /lib64/libm.so.6 -> libm-2.31.so
-rwxr-xr-x 1 root root  87K Feb  2 14:11 /lib64/libresolv-2.31.so
-rw-r--r-- 1 root root 126K Feb  2 14:11 /lib64/libresolv.a
lrwxrwxrwx 1 root root   14 Feb  2 14:11 /lib64/libresolv.so -> libresolv.so.2
lrwxrwxrwx 1 root root   17 Feb  2 14:11 /lib64/libresolv.so.2 -> libresolv-2.31.so

Kinda sad it broke, it seemed to work fine with gcc older, but im guessing its not gcc. Anyone have a clue, idea or trick? building busybox statically could be done in a chroot, buildroot or even on another system (precompiled versions everywhere) but you probably understand I would like to fix this as it has worked before.

I can post more detail on my system if needed. Thank you for reading

Last edited by CodeAsm (2020-02-26 09:41:23)

latalante1 · 2020-02-13 17:48:47

CodeAsm wrote:

/usr/bin/ld: util-linux/lib.a(rdate.o): in function `rdate_main':
rdate.c:(.text.rdate_main+0xf8): undefined reference to `stime'
/usr/bin/ld: coreutils/lib.a(date.o): in function `date_main':
date.c:(.text.date_main+0x22d): undefined reference to `stime'
collect2: error: ld returned 1 exit status

Here you have the necessary patch.
https://bugs.gentoo.org/708350

eschwartz · 2020-02-13 18:18:11

glibc doesn't even do static linking very well, notice:

/usr/bin/ld: libbb/lib.a(inet_common.o): in function `INET6_resolve':
inet_common.c:(.text.INET6_resolve+0x46): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: networking/lib.a(ipcalc.o): in function `ipcalc_main':
ipcalc.c:(.text.ipcalc_main+0x214): warning: Using 'gethostbyaddr' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: libbb/lib.a(inet_common.o): in function `INET_resolve':
inet_common.c:(.text.INET_resolve+0x49): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: networking/lib.a(inetd.o): in function `reread_config_file':
inetd.c:(.text.reread_config_file+0x249): warning: Using 'getservbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: networking/lib.a(netstat.o): in function `ip_port_str':
netstat.c:(.text.ip_port_str+0x50): warning: Using 'getservbyport' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

I recommend doing like the official community/busybox package and using CC=musl-gcc (provided by the musl package).

...

Also generally, given the removal of stime one would assume the dynamically linked build would fail too, so pointing fingers at static building just because you happened to use that, merely serves to confuse people.

CodeAsm · 2020-02-26 09:46:30

Later reply then I wanted,
Thank you both for replying. The patch seemed a bit complicated for what I needed, possibly with some help from a local linux expert I could have made it work but eschwartz reply came allong,
Thank you eschwartz, i had to take a few days to realize you meant the arch official package, learned a few things and found it to work just fine with musl installed aswell.

Thanks for reading, replying and for a solution that worked for me,
Have a wonderfull day

JayceCao · 2020-05-08 12:09:46

@latalante1 's answer is right. I've tested the patch and compiled busybox-1.31.1 successfully. Patch file from busybox's git repository: https://git.busybox.net/busybox/patch/? … 158f08bcd9

mitch_feaster · 2021-03-25 02:54:30

I apologize for the necromancy, but I'm the author of the blog article in OP's question. I recently ran into these same build errors when I was revisiting that post. Hilariously, when I googled the error message I landed here: a forum thread debugging my blog post Isn't that convenient...

Using musl is a cool approach. For what it's worth I've published an updated blog post that punts on these setup issues entirely by using a docker based build environment, so it works on any distro without fiddling with dependencies. Check it out if you're interested or want to get back to glibc: https://mgalgs.github.io/2021/03/23/how … ocker.html

Arch Linux

#1 2020-02-13 16:30:50

[SOLVED] Static building of busybox fails, after update gcc/glibc?

#2 2020-02-13 17:48:47

Re: [SOLVED] Static building of busybox fails, after update gcc/glibc?

#3 2020-02-13 18:18:11

Re: [SOLVED] Static building of busybox fails, after update gcc/glibc?

#4 2020-02-26 09:46:30

Re: [SOLVED] Static building of busybox fails, after update gcc/glibc?

#5 2020-05-08 12:09:46

Re: [SOLVED] Static building of busybox fails, after update gcc/glibc?

#6 2021-03-25 02:54:30

Re: [SOLVED] Static building of busybox fails, after update gcc/glibc?

Board footer