https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: app-arch/gzip-1.12-r4 has implicit function declarations in configure logs (MUSL-CLANG-SYSTEM). Discovered on: amd64 (internal ref: tinderbox_musl) NOTE: (MUSL-CLANG-SYSTEM) in the summary means that bug was found on a machine that runs MUSL libc + clang16 but this bug MAY or MAY NOT BE related to musl/clang16. See also: https://bugs.gentoo.org/898488#c4.
Created attachment 856582 [details] build.log build log and emerge --info
> * /var/tmp/portage/app-arch/gzip-1.12-r4/work/gzip-1.12/config.log:3546 - MIN > * /var/tmp/portage/app-arch/gzip-1.12-r4/work/gzip-1.12/config.log:5356 - fpurge
ci has reproduced this issue with version 1.13 - Updating summary.
This bug is amazing. On glibc, fpurge doesn't exist (__fpurge does). On musl, both exist: https://git.musl-libc.org/cgit/musl/commit/?id=7640497f5f28ddb4aa13528676a99b603320f47e *partially* removed, as in only removed from the header: https://git.musl-libc.org/cgit/musl/commit/?id=a34b0465ba14c70532b8eaba650a9eac228fce57 gnulib promptly misfires all over this, and interestingly also has a cross compile hint that it is assumed to work on musl and skips trying to figure it out. It doesn't, because there is no decl! It sort of does with added UB, if you ignore implicit function declarations and bind to root / # nm -D /usr/lib/libc.so | grep fpurge 0000000000057dc0 T __fpurge 0000000000057dc0 W fpurge This sounds really bad... for gcc 13 and lower. Updating to gcc 14 *fixes* the check because gnulib uses its own copy instead...
tinderbox_musl has reproduced this issue with version 1.13-r1 - Updating summary.
