On Tue, Jul 09, 2024 at 01:05:45PM +0000, Joshua Lant wrote: > Error compiling with musl-libc: > The commit hash 810f8568f44f5863c2350a39f4f5c8d60f762958 introduces the > netinet/ether.h header into xtables.h, which causes an error due to the > redefinition of the ethhdr struct, defined in linux/if_ether.h and > netinet/ether.h. > > This is is a known issue with musl-libc, with kernel headers providing > guards against this happening when glibc is used: > https://wiki.musl-libc.org/faq (Q: Why am I getting “error: redefinition > of struct ethhdr/tcphdr/etc”?) > > The only value used from netinet/ether.h is ETH_ALEN, which is already set > manually in libxtables/xtables.c. Move this definition to the header and > eliminate the inclusion of netinet/if_ether.h. Man, this crap keeps popping up. Last time we "fixed" it was in commit 0e7cf0ad306cd ("Revert "fix build for missing ETH_ALEN definition""). There, including netinet/ether.h was OK. Now it's problematic? Interestingly, linux/if_ether.h has this: | /* allow libcs like musl to deactivate this, glibc does not implement this. */ | #ifndef __UAPI_DEF_ETHHDR | #define __UAPI_DEF_ETHHDR 1 | #endif So it's not like the other party is ignoring musl's needs. Does adding -D__UAPI_DEF_ETHHDR=0 fix the build? Should we maybe add a configure option for this instead of shooting the moving target? Cheers, Phil
