In article <[email protected]>, Riccardo Mottola <[email protected]> wrote: >Hi, > >when using current NetBSD and compiling GNUstep (current objective-c >stuff from svn, not packages) I get for about any obj-c file these >redefinition warnings: > > Compiling file main.m ... >In file included from >/System/Library/Headers/GNUstepBase/GSVersionMacros.h:219:0, > from /System/Library/Headers/AppKit/AppKit.h:32, > from main.m:25: >/System/Library/Headers/GNUstepBase/GSConfig.h:417:0: warning: "__weak" >redefined [enabled by default] > # define __weak > ^ >In file included from /usr/include/sys/cdefs.h:60:0, > from /usr/include/inttypes.h:35, > from /System/Library/Headers/GNUstepBase/GSConfig.h:154, > from >/System/Library/Headers/GNUstepBase/GSVersionMacros.h:219, > from /System/Library/Headers/AppKit/AppKit.h:32, > from main.m:25: >/usr/include/sys/cdefs_elf.h:68:0: note: this is the location of the >previous definition > #define __weak __attribute__((__weak__)) > ^ > >on 6.1.5 instead everything works fine there. On 6.1.5, I see this in >the header file instead: > >#define __weak_reference(sym) __attribute__((__weakref__(#sym))) >
It depends what GNUStep considers itself to be; a system facility or a user program. If GNUStep thinks it owns the __ namespace, and can define macros in that namespace unconditionally, it should try defining __cplusplus, __FILE__, __LINE__, etc. too and see if anything breaks. I sympathize about __weak, but I don't understand what is it trying to do here because I don't have the context in GSConfig.h. It looks to me like it is part of a nested cpp if statement, which perhaps is going the wrong way because it does not know how to handle NetBSD or it fails to detect NetBSD. Nevertheless, defining symbols in the __ space should be protected or avoided. Don't blame NetBSD though, because these are system headers... christos
