> Would this difference explains why there is no redefinition linking > error with musl, or am I missing something?
I don't know. I will ask people who know. It is strange indeed; I didn't even notice that the strnlen sysdep was "no" with musl, else I would have fixed it...
What is the reason for clearing _POSIX_C_SOURCE from trystrnlen.c?
The set of functions made visible by a libc is generally bigger when you do *not* define any POSIX or XOPEN macro: systems don't feel like they have to respect a particular namespace, and export all they have, or close to all they have. _POSIX_C_SOURCE usually means "only declare what is strictly POSIX, and if the application is trying to use an extension, it's an error". This is true even for functions actually defined by POSIX, such as futimens(), the openat() family of functions, and the whole sys/socket.h family of functions; some (arguably old) libcs mistakenly fail to expose them when POSIX macros are defined, but expose them when no such macro is defined. Sometimes they also require a specific extension macro to expose them. The biggest culprits of this are Solaris, MacOS, and NetBSD. The only libcs I've never seen stray from POSIX visibility rules are glibc and musl. And so, when testing a function's existence, I usually remove all POSIX macro definitions, assuming that the visibility will be higher and the function has a higher chance of being detected - so the system's function is used instead of the workaround. In the case of strnlen, though, it appears that this assumption is wrong. I just tested without the undefs, and unless I missed something again, strnlen is correctly detected on all the systems that have it. My bad then, it's a bug. The latest git head performs the trystrnlen.c test without the undefs; please test it. If it works for you, I'll release a new version of skalibs with the fix. -- Laurent