On 2 Nov 2012, at 08:37, Wolfgang Lux wrote: > Am 02.11.2012 um 09:22 schrieb Wolfgang Lux: > >> Am 02.11.2012 um 00:27 schrieb Philippe Roussel: >> >>> Le 01/11/2012 22:07, Riccardo Mottola a écrit : >>>> Hi, >>>> >>>> with the latest changes, if I compile base on NetBSD I get: >>>> Compiling file NSProcessInfo.m ... >>>> In file included from NSProcessInfo.m:86:0: >>>> /usr/include/kvm.h:74:30: error: expected declaration specifiers or >>>> '...' before 'u_long' >>>> /usr/include/kvm.h:83:29: error: expected declaration specifiers or >>>> '...' before 'u_long' >>>> /usr/include/kvm.h:84:30: error: expected declaration specifiers or >>>> '...' before 'u_long' >>> >>> [snip] >>> >>> On ubuntu 12.04 32 bits (gcc 4.6.3) I get the following : >>> >>>> Compiling file NSNetServices.m ... >>>> Compiling file GSAvahiNetService.m ... >>>> GSAvahiNetService.m: In function ‘NSDataFromAvahiAddressPortAndInterface’: >>>> GSAvahiNetService.m:308:11: erreur: ‘const struct in6_addr’ has no member >>>> named ‘s6_addr32’ >> >> Same here for gnu-gnu-gnu on OS X, only it fails already for NSFileManager: >> >> Compiling file NSFileManager.m ... >> In file included from /usr/include/sys/attr.h:42:0, >> from /usr/include/sys/mount.h:76, >> from NSFileManager.m:144: >> /usr/include/sys/ucred.h:91:2: error: unknown type name 'u_long' >> /usr/include/sys/ucred.h:137:9: error: unknown type name 'u_int' >> In file included from /usr/include/sys/mount.h:76:0, >> from NSFileManager.m:144: >> /usr/include/sys/attr.h:77:2: error: unknown type name 'u_short' >> /usr/include/sys/attr.h:432:2: error: unknown type name 'u_long' >> /usr/include/sys/attr.h:444:2: error: unknown type name 'u_char' >> make[4]: *** [obj/libgnustep-base.obj/NSFileManager.m.o] Error 1 >> >> Apparently the problem is the change to Source/common.h in r35764 (by >> reverting that change I could get things to build again). However, it isn't >> obvious to me why this change is causing these problems. > > After a bit of testing, I found the issue. Before the change Source/common.h > would define _XOPEN_SOURCE only for Linux (and even in that case only if the > macro __GNU__ is not defined; I don't know when this is supposed to be > defined and when not) and for QNX(?). After the change it now does that for > every platform other than FreeBSD and that seems incorrect.
We need to figure out how to determine what systems this needs to be defined on ... I restructured the code to make it really easy to clearly control the defines for different individual systems, but Ideally we'd have some reliable wayfor determining if glibc is in use. Unfortunately, I read that we can't use _GLIBC_ because other libc implementations define that in order to pretend that they are glibc! _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
