Created attachment 445000 [details] Full build log. When compiling halts, it looks like this: In file included from interface.c:40:0: ethtool-local.h:25:9: error: unknown type name '__uint32_t' typedef __uint32_t u32; ^ ethtool-local.h:26:9: error: unknown type name '__uint16_t' typedef __uint16_t u16; ^ ethtool-local.h:27:9: error: unknown type name '__uint8_t' typedef __uint8_t u8; ... and so on... I believe this is musl-related because the __uintNN_t usage looks not-totally-portable and ifplugd has always compiled fine for me on non-musl profiles. It probably just needs some #include <stdint.h>
Created attachment 445002 [details, diff] Patch. This patch allows it to compile successfully on my system.
Patch looks good. Thanks! This bug should block bug 430702 and be reassigned to base-system.
Thank you for working on the musl port :) I did not know about bug 430702. I suppose if I run into other notable broken builds then I will make those block it too (while checking for dups, of course).
Yes, all build failures related to musl should block that bug.
sys-apps/ifplugd-0.28-r10 now has your patch, and should build without problems.
sys-apps/ifplugd-0.28-r10 compiles fine on my system. :) Please mask sys-apps/ifplugd-0.28-r9 in the hardened-musl profile if you're not going to patch it too. People like me who tend to merge stable packages by default would get the unpatched r9 currently in the tree and it would break their build.
Cool thanks, I think that is also a good idea :) Hope it works.
(In reply to Chad Joan from comment #6) > sys-apps/ifplugd-0.28-r10 compiles fine on my system. :) > > Please mask sys-apps/ifplugd-0.28-r9 in the hardened-musl profile if you're > not going to patch it too. People like me who tend to merge stable packages > by default would get the unpatched r9 currently in the tree and it would > break their build. Only versions left in Gentoo work! \o/
