https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/ Issue: net-misc/asterisk-18.18.0 fails to compile (MUSL-SYSTEM). Discovered on: amd64 (internal ref: tinderbox_musl) NOTE: (MUSL-SYSTEM) in the summary means that bug was found on a machine that runs MUSL libc but this bug MAY or MAY NOT BE related to musl.
Created attachment 863312 [details] build.log build log and emerge --info
tinderbox_musl has reproduced this issue with version 21.1.0 - Updating summary.
line in git blame: 94b934c8f66 main/ast_expr2.y (Steve Murphy 2007-07-02 21:50:15 +0000 277) static int chk_div __P((FP___TYPE, FP___TYPE)); __P perhaps not #define's for some reason on musl? What would have changed, because this worked previously I believe. Or it could be glibc vs musl again. Looking in /usr/include it seems sys/cdefs.h performs a #define for __P - is this glibc specific? Will it fix the MUSL compile to simply add #include <sys/cdefs.h> to the relevant file?
(In reply to Jaco Kroon from comment #3) > Looking in /usr/include it seems sys/cdefs.h performs a #define for __P - is > this glibc specific? Will it fix the MUSL compile to simply add #include > <sys/cdefs.h> to the relevant file? I'm no musl expert and haven't really looked at this, but no. sys/cdefs.h does not exist with musl. Also, even with glibc relying on __P being defined sound flaky and per the comment is only kept to avoid breaking things it looks like (does nothing): /* These two macros are not used in glibc anymore. They are kept here only because some other projects expect the macros to be defined. */ #define __P(args) args #define __PMT(args) args If attempt any fix, I'd suggest trying it out in a quick stage3 musl chroot anyhow.
makes sense because the #define is basically #define __P(args) args Asterisk does have a compat.h file which should #define it if it's not done. Which is included from asterisk.h ... but apparently only for solaris. Engaging the asterisk devs. Thanks for the feedback.
