Hi Frank, Thanks for bringing this up - it's indeed a nasty problem (although hopefully pretty easy to fix :)
A year or two ago I was working on updating macports patches for building GNUstep on OS X 10.6/10.7, and ran in to an instance of this here: https://github.com/ericwa/gnustep-macports-fixes/blob/master/gnustep/gnustep-back/files/patch-CairoFaceInfo.h I forget the details but I think I was working around GNUstep pulling in OS X's MAC_OS_X_VERSION_MAX_ALLOWED. My take on it is, we (GNUstep) should avoid using symbols that Apple is shipping in their availability macros, since the availability macros on OS X are included in standard C headers (e.g. /usr/include/stdlib.h). I'd propose modifying this section of base/Headers/GNUstepBase/GSVersionMacros.h: /* * For MacOS-X compatibility, we define the MacOS-X version constants and * we allow MAC_OS_X_VERSION_MIN_ALLOWED or MAC_OS_X_VERSION_MAX_ALLOWED * instead of GS_OPENSTEP_V */ #ifndef MAC_OS_X_VERSION_10_0 #define MAC_OS_X_VERSION_10_0 100000 #define MAC_OS_X_VERSION_10_1 100100 #define MAC_OS_X_VERSION_10_2 100200 #define MAC_OS_X_VERSION_10_3 100300 #define MAC_OS_X_VERSION_10_4 100400 #define MAC_OS_X_VERSION_10_5 100500 #define MAC_OS_X_VERSION_10_6 100600 #endif /* MAC_OS_X_VERSION_10_0 */ #ifndef GS_OPENSTEP_V #ifdef MAC_OS_X_VERSION_MIN_ALLOWED #define GS_OPENSTEP_V MAC_OS_X_VERSION_MIN_ALLOWED #else #ifdef MAC_OS_X_VERSION_MAX_ALLOWED #define GS_OPENSTEP_V MAC_OS_X_VERSION_MAX_ALLOWED #endif /* MAC_OS_X_VERSION_MAX_ALLOWED */ #endif /* MAC_OS_X_VERSION_MIN_ALLOWED */ #endif /* GS_OPENSTEP_V */ We could rename the MAC_OS_X_VERSION_* to GS_OS_X_VERSION_*, and eliminate the section below that makes MAC_OS_X_VERSION_MIN_ALLOWED or MAC_OS_X_VERSION_MAX_ALLOWED an alias for GS_OPENSTEP_V. Maybe someone who has more background on the history of these macros in GS can chime in? Eric On 2013-06-03, at 6:06 PM, Frank Rehwinkel <[email protected]> wrote: > I think the build is currently broken on OS X 10.8 and I think there are > typos so I was just asking for experienced advice what path to take to fix > it. I guess it's also possible it is not broken for other people on their > 10.8 systems but if that's the case, I'd like to hear about it. > > Thanks, > -Frank > > > On Mon, Jun 3, 2013 at 6:00 PM, Maxthon Chan <[email protected]> wrote: > Don't panic, as Apple will switch back in no more than 2 years - when they > reached OS X 10.10 (OS X 10.9 is pretty much confirmed in this year's WWDC - > I am a paid iOS developer so I have access to these "Apple Prerelease" > information. Or maybe at that time there will be no more OS X, and the new OS > is called iOS 11 all across desktop and mobile devices). > > 在 2013-6-4，上午5:55，Frank Rehwinkel <[email protected]> 写道： > >> I'm confused by GNUstep's use of the MAC_OS_X_VERSION macros which are >> similar but not identical to Apple's and by what appear >> to be typos in some of their use. >> >> The system headers in my OS X 10.8 system define four digit version numbers >> but >> GNUstep is built on six digit version numbers. Also Apple's documentation >> gives an example of using a four digit number, 1050, to represent the 10.5 >> version of OS X. >> >> http://developer.apple.com/library/ios/#documentation/DeveloperTools/Conceptual/cross_development/Using/using.html#//apple_ref/doc/uid/20002000-SW6 >> >> Was Apple's version number once six digits or was it always four and GNUstep >> needed/wanted to use six? At the moment, the test for OS X version is broken >> because the four digit value is being picked up from the system header (1080) >> and it works out to be less than an old version number because fewer digits >> are >> being used (100500 in the first case I tracked down). >> >> The simplest fix would seem to be to stick with six digits for GNUstep-base >> but fix >> the one header that was responsible for pulling in a value of 1080 as the >> current >> max value. We could hardcode a current max value of 100800. >> >> Also it appears there are some symbols being tested against that aren't even >> declared in the headers. They appear to be typos because they are so similar >> to valid symbols. >> >> And it appears GNUstep-base hasn't been updated for OS X since 10.6 or 10.7. >> The >> file GNUstepBase/GSVersionMacros.h defines these constants, among others. >> There are no constants that would map to 10.7 or 10.8, but NSCalender.h does >> use MAC_OS_X_VERSION_10_7. So these tests appear to be broken at the moment. >> >> GNUstepBase/GSVersionMacros.h: >> #ifndef MAC_OS_X_VERSION_10_0 >> #define MAC_OS_X_VERSION_10_0 100000 >> #define MAC_OS_X_VERSION_10_1 100100 >> #define MAC_OS_X_VERSION_10_2 100200 >> #define MAC_OS_X_VERSION_10_3 100300 >> #define MAC_OS_X_VERSION_10_4 100400 >> #define MAC_OS_X_VERSION_10_5 100500 >> #define MAC_OS_X_VERSION_10_6 100600 >> #endif /* MAC_OS_X_VERSION_10_0 */ >> >> Note: these symbols are defined in /usr/include/AvailabilityMacros.h. I >> can't >> imagine Apple switched from a six digit scheme to a four digit scheme without >> changing the symbol names because their own documentation advises using >> hardcoded numbers instead of symbol names. But I also can't imagine GNUstep >> would have used the same symbol names in a different manor. It would have >> been >> just as easy to use a different symbol name pattern to represent GNUstep's >> version of the OS version. I can't find a reference to such a change >> happening >> so maybe GNUstep code was always doing its own thing. >> >> /usr/include/AvailabilityMacros.h: >> /* >> * Set up standard Mac OS X versions >> */ >> #define MAC_OS_X_VERSION_10_0 1000 >> #define MAC_OS_X_VERSION_10_1 1010 >> #define MAC_OS_X_VERSION_10_2 1020 >> #define MAC_OS_X_VERSION_10_3 1030 >> #define MAC_OS_X_VERSION_10_4 1040 >> #define MAC_OS_X_VERSION_10_5 1050 >> #define MAC_OS_X_VERSION_10_6 1060 >> #define MAC_OS_X_VERSION_10_7 1070 >> #define MAC_OS_X_VERSION_10_8 1080 >> >> The place where this bites us now when building for OS X is that Apple's >> symbol, MAC_OS_X_VERSION_MAX_ALLOWED, gets pulled in from a system header, >> AvailabilityInternal.h and is used to test against the six digit values. >> >> /usr/include/AvailabilityInternal.h: #define >> __MAC_OS_X_VERSION_MAX_ALLOWED __MAC_10_8 >> >> But Apple defines __MAC_10_8 like this: >> >> /usr/include/Availability.h:#define __MAC_10_8 1080 >> >> And defining it as 1080 instead of 100800 breaks the assumptions in the >> GNUstep-base code. Examples: >> >> NSPointerFunctions.h: #if OS_API_VERSION(100500, GS_API_LATEST) >> >> 100500 would be less than 100800 but it is not less than 1080, so code that >> should be expanded by the preprocessor is not, and the build fails. >> >> All these OS X version checks in the code could be changed from the hardcoded >> numbers like the example above in NSPointerFunctions.h to use symbol names if >> we wanted to support some systems where the digits were four and others where >> they were six. But that would mess up anyone who had defined the current >> symbol >> in their build script. >> >> Grep'ing through the -base code for OS_API_VERSION, there are over 300 uses >> of >> the macro, but only 20 unique forms really: >> >> #if OS_API_VERSION(100200, GS_API_LATEST) >> #if OS_API_VERSION(100300, GS_API_LATEST) >> #if OS_API_VERSION(100400, GS_API_LATEST) >> #if OS_API_VERSION(100500, GS_API_LATEST) >> #if OS_API_VERSION(100600, GS_API_LATEST) >> #if OS_API_VERSION(100700, GS_API_LATEST) >> #if OS_API_VERSION(GSAPI_MACOSX, GS_API_LATEST) >> #if OS_API_VERSION(GSAPI_NONE, GSAPI_NONE) >> #if OS_API_VERSION(GS_API_MACOSX, GS_API_LATEST) >> #if OS_API_VERSION(GS_API_MACOSX, HS_API_LATEST) >> #if OS_API_VERSION(GS_API_NONE, GS_API_LATEST) >> #if OS_API_VERSION(GS_API_NONE, GS_API_NONE) >> #if OS_API_VERSION(GS_API_OPENSTEP, GS_API_MACOSX) >> #if OS_API_VERSION(GS_API_OSSPEC, GS_API_LATEST) >> #if OS_API_VERSION(MAC_OS_X_VERSION_10_2, GS_API_LATEST) >> #if OS_API_VERSION(MAC_OS_X_VERSION_10_4, GS_API_LATEST) >> #if OS_API_VERSION(MAC_OS_X_VERSION_10_4, OS_API_LATEST) >> #if OS_API_VERSION(MAC_OS_X_VERSION_10_5, GS_API_LATEST) >> #if OS_API_VERSION(MAC_OS_X_VERSION_10_6, GS_API_LATEST) >> #if OS_API_VERSION(MAC_OS_X_VERSION_10_7, GS_API_LATEST) >> >> >> Here are the unique definitions for the symbols used in the GNUstep calls to >> OS_API_VERSION(), listed in order of there constant values. >> >> *** GS_API_NONE >> ./Headers/GNUstepBase/GSVersionMacros.h:#define GS_API_NONE 0 >> >> *** GS_API_OSSPEC >> ./Headers/GNUstepBase/GSVersionMacros.h:#define GS_API_OSSPEC 10000 >> ./Tools/AGSHtml.m:#define GS_API_OSSPEC 10000 >> >> *** GS_API_OPENSTEP >> ./Headers/GNUstepBase/GSVersionMacros.h:#define GS_API_OPENSTEP 40000 >> ./Tools/AGSHtml.m:#define GS_API_OPENSTEP 40000 >> >> *** GS_API_MACOSX >> ./Headers/GNUstepBase/GSVersionMacros.h:#define GS_API_MACOSX 100000 >> ./Tools/AGSHtml.m:#define GS_API_MACOSX 100000 >> (Could change this to MAC_OS_X_VERSION_10_0 to make it more readable but >> probably that's getting carried away.) >> >> *** GS_API_LATEST >> ./Headers/GNUstepBase/GSVersionMacros.h:#define GS_API_LATEST 999999 >> >> ***** And four symbols used a handful of times that look in error. >> >> *** OS_API_LATEST - only appears in Foundation/NSZone.h >> (no definition found - perhaps typo in Foundation/NSZone.h - >> could change OS_... to GS_...) >> >> *** GSAPI_MACOSX - only appears in Foundation/NSUserDefaults.h >> (no definition found - perhaps typos in Foundation/NSUserDefaults.h - could >> change GSAPI_... to GS_API_...) >> >> *** GSAPI_NONE - also only appears in Foundation/NSUserDefaults.h >> (no definition found - perhaps typo in Foundation/NSUserDefaults.h - could >> change GSAPI_... to GS_API_...) >> >> *** HS_API_LATEST - only used in Headers/Foundation/NSPortNameServer.h >> (no definition found - probably a typo of GS_API_LATEST) >> >> Should the GNUstep-base macros be based on four digit OS X version numbers >> or six digit? >> If left as six digits, should the lines that use symbols like >> MAC_OS_X_VERSION_10_7 >> be changed to use the hard coded numbers like 100700? To avoid any possible >> ambiguity >> later on from the four digit symbols appearing in the Apple headers? >> >> Thanks, >> -Frank >> >> _______________________________________________ >> Gnustep-dev mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
