I'm sure there's a far better way dealing with the preprocessors, but here's a simple patch attached that got vim to compile and work for me.
This code path probably didn't get hit for quite a while, at least since 10.4. And since 10.5, that particular system call takes a separate type of variable, stack_t, rather than sigalstack. Confirmed by looking at
https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/10.5/man2/sigaltstack.2.html
However, I will note, that perhaps a better fix is adding the following:
#include <Availability.h>
That gets you the following:
<snip>
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1090
#define __MACH__ 1
#define __MAC_10_0 1000
#define __MAC_10_1 1010
#define __MAC_10_2 1020
#define __MAC_10_3 1030
#define __MAC_10_4 1040
#define __MAC_10_5 1050
#define __MAC_10_6 1060
#define __MAC_10_7 1070
#define __MAC_10_8 1080
#define __MAC_10_9 1090
#define __MAC_OS_X_VERSION_MAX_ALLOWED __MAC_10_9
#define __MAC_OS_X_VERSION_MIN_REQUIRED __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__
<snip>
I also note one of the more common header files, stdio.h, has an #include for Availability.h.
I believe this has to with the complete conversion from LLVM+GCC to clang with XCode 5's SDK:
OS 10.9:
mirell at chibi ~/src/bitbucket gcc --version
Configured with: --prefix=/Applications/Xcode5-DP.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode5-DP.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.1.58) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
OS 10.8:
gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
In any case, it's too soon to tell whether they'll reinclude those variables for future releases, however I think making the patch inline with what the current headers define the struct as will suffice.
Thanks!
--
Tryn Mirell
tr...@mirell.org
https://mirell.org