error: expected a platform name, e.g., 'macosx'
Ryan Schmidt
ryandesign at macports.org
Sat Sep 22 02:51:40 PDT 2012
I want to alert port maintainers to a strange error message users might report starting on Mountain Lion:
/usr/include/sys/stat.h:451:40: error: expected a platform name, e.g., 'macosx'
int lchflags(const char *, __uint32_t) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
^
/usr/include/Availability.h:153:50: note: expanded from macro '__OSX_AVAILABLE_STARTING'
#define __OSX_AVAILABLE_STARTING(_osx, _ios) __AVAILABILITY_INTERNAL##_osx
^
<scratch space>:9:1: note: expanded from macro '__AVAILABILITY_INTERNAL'
__AVAILABILITY_INTERNAL__MAC_10_5
^
/usr/include/AvailabilityInternal.h:1084:100: note: expanded from macro '__AVAILABILITY_INTERNAL__MAC_10_5'
#define __AVAILABILITY_INTERNAL__MAC_10_5 __attribute__((availability(macosx,introduced=10.5)))
^
<command line>:1:16: note: expanded from macro 'macosx'
#define macosx 1
^
It's strange because on first glance the error appears to be in a system header. We recently fixed this problem in four ports but it took awhile to figure out what was happening so I wanted to explain in case anyone runs into it with other ports.
The system headers use availability macros, and at least on Mountain Lion their definitions include the word "macosx", e.g. "availability(macosx,introduced=10.5)". The problem occurs when a software package defines its own preprocessor symbol called "macosx". This might take the form of a "#define macosx" inserted into a confdefs.h file by a configure script, or a hand-written Makefile specifying "-Dmacosx". The four projects we recently fixed used this symbol to include code meant only for use on OS X, and for that use case, custom defines aren't necessary because there's already a define available for that purpose on OS X: "__APPLE__". So the fix is to remove the custom "macosx" preprocessor symbol from the project, and to change any "macosx" checks in the source files to checks for "__APPLE__" instead.
Here are the various ways this was fixed in the four ports:
guile16: https://trac.macports.org/changeset/98017
iozone: https://trac.macports.org/changeset/98018
irsim: https://trac.macports.org/changeset/97986
magic: https://trac.macports.org/changeset/97859
I've sent the fixes for iozone, irsim and magic to their developers. (guile16 is an old version that they're not releasing new versions of anymore.) If you develop a fix for this problem in another port, be sure to send it to its developers for inclusion upstream.
More information about the macports-dev
mailing list