On 06/17/2012 02:56 PM, Rich Felker wrote: >> 1) Currently, gnulib has to go to a great length to detect musl. >> It uses the presence of __stdio_read and __stdio_write as an indicator; > That's not valid. These are internal functions that could be renamed > or disappear (e.g. be changed to visibility=hidden) at any time.
OK, so why not change musl to define a symbol like __MUSL__ that will make gnulib's job easier? The arguments given so far against such a symbol seem to be based primarily on theoretical objections, which don't have much practical force. The argument for having a symbol is based on real code that we need to write. > will configure even find them? Yes, it can be made to find them, as part of gnulib. > a big part of musl's design goal has been to avoid implementation > lock-in caused by exposing internals to applications. And a big part of gnulib's design goal is to provide useful functionality that is portable and efficient on practical systems. These goals clash. Sorry, but that's life. Now, we have to decide what to do about it. To us, conforming to the standard is merely a means towards writing portable and efficient software. If not-conforming to the standard achieves the goal better, then we will fail to conform to the standard. For us, standards are our servants, not our masters. This is a pragmatic approach that works well in practice. Bruno has ported it to musl too, which is a good thing. It would be nicer if the port used "approved" musl interfaces, but if musl can't or won't do that we'll just have to continue to poke under musl's covers to get the behavior that we want, just like we do with many other libraries. If these libraries change in the future, gnulib will too. But it would be better if musl provided better interfaces for this useful functionality; as that would make gnulib-based applications more likely to port to future musl implementations without hassle.
