Created attachment 355852 [details, diff] Patch for glib-2.36.3 =dev-libs/glib-2.36 checks for the presence of fallocate using a link-only check. That is, it tries to compile and link a program that uses fallocate. Glibc-2.15 is subtly broken in this regard: while the binary has the symbols (and thus linking works), the associated header file (fcntl.h) is incomplete and does not contain a complete prototype for the fallocate() call. Glib by default compiles all sources using -Werror=implicit-function-declaration among other flags. Naturally, this fails with fallocate: the symbol is there and thus configure sets HAVE_FALLOCATE=1, but the compile step fails due to the missing prototype. Since usage of fallocate() is optional in glib and we're not sure the glibc-2.15 implementation of it may be buggy (explaining the absent prototype, maybe), forcing glib to do a header-check at configure time seems to be the right approach. I've attached a patch that axs@ made. I've tested it on monolith.alpha.dev.g.o and compiled & run a few deps against it -- it works just fine. I'm aware that this could be fixed in glibc instead -- but recompiling that takes much longer than for glib, and arguably the check is broken for the way glib compiles its sources. I'm also aware that this is currently only triggered by mixing stable glibc with testing glib on Alpha. However, since glibc-2.17 is actually _broken_ on Alpha in a really bad way, it will never go stable, but glib-2.36.* might.
I am also unsure if we should pass Werror for glib compilation :/
Wouldn't dropping -Werror just hide issues rather than force them to be fixed?
Well, in general we don't want -Werror but, in this exact case, where is the problem exactly? glibc or glib check? If it's glib check, I have no problem in applying the patch, but it should also be reported to upstream :)
Problem could be glibc, but (at least on alpha) glibc-2.17 has its own issues. glibc-2.15 does seem to have something strange going on in terms of the 'posix_fallocate' for alpha and whatever the actual object is in the libs. Essentially what seems to happen is that because there's an object in glibc that will match the link-time check that AC_CHECK_FUNCS() does, glib's config enables HAVE_FALLOCATE. However, posix_fallocate will -not- work as a replacement for fallocate() as per glibc on say, x86. So glib will fail if HAVE_FALLOCATE is true (which it is without this patch). This patch essentially just changes the check to be against the glibc headers instead of against the lib, which allows fallocate support to be detected properly in accordance with the function name. Should work everywhere.
In that case, please open a bug upstream at bugzilla.gnome.org forwarding the patch (and your rationale) and, then, I think you can apply this patch downstream on Gentoo (but also adding a comment in epatch line pointing to upstream report for following it in upcoming version bumps ;)) Thanks
Any news on this?
glib-2.38.2-r1 (current stable) compiles fine with glibc 2.17 (ditto). As such, I think we can close this as obsolete.
