GNOME Bugzilla – Bug 756590
build failure with uClibc due to use of __libc_free/__libc_malloc
Last modified: 2016-12-13 13:17:36 UTC
Created attachment 313334 [details] [review] expand check to cover both musl and uClibc. Since pixbuf-lowmem uses glibc internals it doesn't build on other libc's like musl or uClibc. Commit e1fd25a fixed this issue for musl by testing if __GLIBC__ is set and basically stubbing out the test if it isn't. However, uClibc sets a value for __GLIBC__ and so this check is insufficient there. By expanding the test from #ifdef __GLIBC__ to #if defined(__GLIBC__) && !defined(__UCLIBC__) you'll get the desired behavior on all three libcs: it'll build and run for glibc and it'll be stubbed out for musl and uClibc. This has been tested.
Thats really uClibc's fault... if it isn't glibc, it shouldn't define __GLIBC__. I'm really not in favor of more noise just to deal with fringe libc alternatives.
(In reply to Matthias Clasen from comment #1) > Thats really uClibc's fault... if it isn't glibc, it shouldn't define > __GLIBC__. I'm really not in favor of more noise just to deal with fringe > libc alternatives. uClibc introduced the macro because it aims to have some compliance with glibc, although I've come to disagree with the use of all such macros. One should simply check for functions and other system features using configure.ac otherwise you get into exactly this problem. This is why musl doesn't define __MUSL__. The problem stated here with the introduction of calls to glibc internals, namely __libc_malloc() et al. We've been shipping gdk-pixbuf for embedded systems in gentoo for a long time now and would like to keep doing so. Do you have a suggestion for an alternative solution? Maybe add AC_CHECK_FUNC([__libc_malloc], ...)?
I would suggest to simply patch out the testcase for your system.
(In reply to Matthias Clasen from comment #3) > I would suggest to simply patch out the testcase for your system. I know this is an old bug, and we have been carrying this patch forward downstream, but I'd still like to get it upstream. The idea in uClibc is that it shares code with glibc. So as a result, if one wants code which is *in* glibc but *not in* uClibc one uses `defined(__GLIBC__) && !defined(__UCLIBC__)`. The two macros allow one to make various combinations of the two sets and so uClibc defines both marcos. Again, these macros are all bad ideas. One should use autotools to do and AC_CHECK_FUNC() or AC_CHECK_HEADERS() unambiguously target the feature in question.
Reopen if you have a patch for the configure script to remove the hard-coded check on glibc, as we have no way to test this and consider it a self-inflicted uclibc problem.