Masanori Ogino <masanori.og...@gmail.com> writes: >> So I suppose the only feasible option here is to somehow whitelist the >> implementations by checking macros or symbols. Does musl provides >> anything like that[1]? > > No, it doesn't on purpose. Here is the entry on this topic in the FAQ: > http://wiki.musl-libc.org/wiki/FAQ#Q:_why_is_there_no_MUSL_macro_.3F > > Also, I'd like to point out some detailed explanations in a recent discussion: > http://www.openwall.com/lists/musl/2016/03/23/6 > http://www.openwall.com/lists/musl/2016/03/23/7 > http://www.openwall.com/lists/musl/2016/03/23/9
Thanks for the information. > That is why I proposed to have a blacklist of "broken" implementations > as an option. > > AFAIK there have already been some blacklisting in autotools e.g. > checking the version of glibc to reject specific broken implementation > of a function. Thus, I think it's acceptable to use a blacklist. What > do you think about it? Yes, that sounds like a good idea. But I guess we then need to collect information about incompatible implementations. In this regard I'm actually not sure if the gettext-tools test coverage can be used as an indicator of compatibility. By the way, musl defines __GNU_GETTEXT_SUPPORTED_REVISION in the same way as glibc: #define __GNU_GETTEXT_SUPPORTED_REVISION(major) ((major) == 0 ? 1 : -1) Is major = 1 + minor = 1 actually supported in musl? After briefly checking Solaris 11 variants have: #define __GNU_GETTEXT_SUPPORTED_REVISION(m) \ ((((m) == 0) || ((m) == 1)) ? 1 : -1) Regards, -- Daiki Ueno