I’ll be honest, this is a short post because the aggregation on planet.gentoo.org is failing for my account! So, Jorge (jmbsvicetto) is debugging it and I need to push out another blog entry to trigger venus, the aggregation program. Since I don’t like writing trivial stuff, I’m going to write something short, but hopefully important.
C Standard libraries, like glibc, uClibc, musl and the like, were born out of a world in which every UNIX vendor had their own set of useful C functions. Code portability put pressure on various libc to incorporate these functions from other libc, first leading to to a mess and then to standards like POSIX, XOPEN, SUSv4 and so on. Chpt 1 of Kerrisk’s The Linux Programming Interface has a nice write up on this history.
We still live in the shadows of that world today. If you look thorugh the code base of uClibc you’ll see lots of macros like __GLIBC__, __UCLIBC__, __USE_BSD, and __USE_GNU. These are used in #ifdef … #endif which are meant to shield features unless you want a glibc or uClibc only feature.
musl has stubbornly and correctly refused to include a __MUSL__ macro. Consider the approach to portability taken by GNU autotools. Marcos such as AC_CHECK_LIBS(), AC_CHECK_FUNC() or AC_CHECK_HEADERS() unambiguously target the feature in question without making the use of __GLIBC__ or __UCLIBC__. Whereas the previous approach globs together functions into sets, the latter just simply asks, do you have this function or not?
Now consider how uClibc makes use of both __GLIBC__ and __UCLIBC__. If a function is provided by the former but not by the latter, then it expects a program to use
#if defined(__GLIBC__) && !defined(__UCLIBC__)
This is getting a bit ugly and syntactically ambiguous. Someone not familiar with this could easily misinterpret it, or reject it.
So I’ve hit bugs like these. I hit one in gdk-pixbuf and I was not able to convince upstream to consistently use __GLIBC__ and __UCLIBC__. Alternatively I hit this in geocode-glib and geoclue, and they did accept it. I went with the wrong minded approach because that’s what was already there, and I didn’t feel like sifting through their code base and revamping their build system. This isn’t just laziness, its historical weight.
So kudos to musl. And for all the faults of GNU autotools, at least its approach to portability is correct.
Commenting on my own blog post is bad form, I know, but I did make one mistake I want to correct. __USE_GNU is purely internal as is __USE_BSD. I was thinking of _GNU_SOURCE, _BSD_SOURCE and the like. See `man 7 feature_test_macros`.
Actually, I just learned there are some more such questionable macros that you can obtain with `gcc -dM -E – < /dev/null` Most of these are innocent, but I can't help but wonder about things like __linux, __linux__, __gnu_linux__ and linux.
Been late on the systemd mess. Maybe __linux__ is for dudes who like that? You know, just don’t care about standards and throw portability out of the way in the name of features?