gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On linux too (was Re: Base compilation broken on NetBSD)


From: Wolfgang Lux
Subject: Re: On linux too (was Re: Base compilation broken on NetBSD)
Date: Fri, 2 Nov 2012 09:37:25 +0100

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.

Wolfgang




reply via email to

[Prev in Thread] Current Thread [Next in Thread]