There are a few changes in glibc-2.10 that might make your software fail to build with it, please refer to my blog post [1] if you're not sure what the problem is. Also make sure to fix it rather than sidestepping the issue [2] and [3]. And no I don't usually provide emerge --info with these bugs because they are caused by glibc-2.10! Thanks, Diego [1] http://blog.flameeyes.eu/2009/05/24/c-libraries-galore [2] http://blog.flameeyes.eu/2009/07/02/how-_not_-to-fix-gcc-4-4-bugs [3] http://blog.flameeyes.eu/2009/07/08/how-_not_-to-fix-glibc-2-10-function-collisions
Created attachment 198311 [details] Build log
Ok, while looking at this one, I found two things: * this "Assumed value of MB_LEN_MAX wrong" from stdlib.h is strange, and this may be a problem in gnustep base itself (from the long include path). Moreover it disappears with empty CFLAGS (probably -O2)... * second, I've realized that as for now, changing CFLAGS/LDFLAGS/... requires gnustep-make re-merging to take into account :/ (it loads CFLAGS and other vars from /usr/GNUstep/System/Library/Makefiles/config.make, not from environment). If this is confirmed for other packages, an ewarn in gnustep-make could be useful, before ideally managing to override it. Adding to todo list...
Ok, found it: limits.h is sometimes included by #import instead of #include, and with optimization it somehow believes it's already included, and does not load it, which leads to the error in stdlib.h Fixed in 0.8.3 (version bump at the same time)!