Hi,

busybox fails to build from source on arm64 when using glibc 2.43,
currently in experimental.

The issue is triggered by glibc 2.43 on arm64 enabling 2MB THP by
default:
https://sourceware.org/git/?p=glibc.git;a=commit;h=321e1fc73f53081d92ba357cdd48c56b79292020

The problem is however not architecture-specific. For example it can be
reproduced with glibc 2.42 on amd64 by building the package with the
GLIBC_TUNABLES environment variable set to glibc.malloc.hugetlb=2.

Successful build with glibc 2.42, currently in sid:
https://people.debian.org/~ema/glibc-2.43-rebuilds/output-2/busybox_arm64.build

Logs of a failed build with glibc 2.43 are here:
https://people.debian.org/~ema/glibc-2.43-rebuilds/output-1/busybox_arm64.build

Salient part:

FAIL: printf understands %s '"x' "'y" "'zTAIL"
[...]
FAIL: printf handles positive numbers for %f
[...]
PASS: xxd -p -r ignores the nibble with 2nd char bad
2 failure(s) detected; running with -v (verbose) will give more info
make[2]: *** [debian/rules:135: b/deb/.stamp-test] Error 1
make[2]: Leaving directory '/build/reproducible-path/busybox-1.37.0'
make[1]: *** [debian/rules:60: install] Error 2
make[1]: Leaving directory '/build/reproducible-path/busybox-1.37.0'
make: *** [debian/rules:60: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess failed with exit status 2

control: tag -1 + patch

Hi,

The problem happens because of the common misconception that errno is
only set in case of errors. It is therefore used as an accumulator in
some parts of the printf busybox applet. Now that malloc() sets errno to
ENOENT in some cases on arm64, even with successfully allocation, this
causes the above issues.

Please find attached a naive implementation of a fix, basically saving
and restoring errno around printf calls. There is probably a better fix
possible, but it implies refactoring a significant part of the file to
actually return errors differently.

Regards
Aurelien