在Lion之前的OSX版本中，我使用/usr/X11路径构建了X11应用程序。它适用于Tiger和Snow Leopard。
Lion之后，由于我不再记得的原因（我认为这与避免来自不同SDK版本的标题不匹配有关），我改变了这种方法并编译了所有X11应用程序，完全避免使用/usr并使用而是：-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.x.sdk（其中'MacOSX10.x.sdk'中的'x'是正在使用的SDK版本）。这种构建X11应用程序的方法在Mountain Lion和Yosemite中对我来说很好。
但是，现在我将系统更新为El Capitan，并且X11应用程序配置脚本无法再使用-isysroot找到X11。
看，这就是我现在用El Capitan得到的东西，做得和山狮和优胜美地一样好用：
creating cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal-1.4... missing
checking for working autoconf... missing
checking for working automake-1.4... missing
checking for working autoheader... missing
checking for working makeinfo... found
checking for gcc... gcc
checking whether the C compiler (gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.11 -L/usr/X11R6/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.11) works... yes
checking whether the C compiler (gcc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.11 -L/usr/X11R6/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -mmacosx-version-min=10.11) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking how to run the C preprocessor... gcc -E
checking for gcc option to accept ANSI C... none needed
checking for Cygwin environment... no
checking for mingw32 environment... no
checking host system type... i386-apple-darwin15.0.0
checking build system type... i386-apple-darwin15.0.0
checking for ld used by GCC... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm
checking for a sed that does not truncate output... /usr/bin/sed
checking whether ln -s works... yes
checking how to recognise dependent libraries... file_magic Mach-O dynamically linked shared library
checking for object suffix... o
checking for executable suffix... no
checking command to parse /usr/bin/nm output... ok
checking for dlfcn.h... yes
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... unsupported
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... darwin15.0.0 dyld
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... no
checking whether to build static libraries... yes
creating libtool
checking for executable suffix... (cached) no
checking for byacc... no
checking for flex... flex
checking for flex... (cached) flex
checking for yywrap in -lfl... no
checking lex output file root... lex.yy
checking whether yytext is a pointer... no
checking for a BSD compatible install... /usr/bin/install -c
checking whether ln -s works... (cached) yes
checking whether make sets ${MAKE}... (cached) yes
checking for X... no
我看到我的系统中存在/usr/X11（它实际上是指向/ opt / X11的链接，因为El Capitan不允许非Apple用户/usr，但/opt/X11正确存在，包含所有X11头文件和库。）
这是否意味着无法再使用-isysroot构建X11应用程序？我是否需要使用系统根包含路径（存在于/usr/include，BTW中）构建它们？ （我的系统甚至有/usr/include/stdio.h和所有标准标题，我不知道为什么，因为我相信所有标题都已移到SDK中。
如果是肯定的，我不相信包括来自/ usr / include而不是SDK包含路径...这让我感到害怕SDK不匹配......
谢谢！
答案 0 :(得分：1)
从SDK-correctness的角度来看，不确定这个解决方案是否正确，但在10.11 El Capitan中，似乎设置'-isysroot'已不足以编译X11应用程序。
因此，尝试仅使用SDK中的标头，并仅使用X11标头补充它们（因此唯一的“局外人”是X11标头），我发现此解决方案有效：
编译行的选项：-I/opt/X11/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
链接行的选项：-L/opt/X11/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk
正如我所说，我不知道这是否是正确的做法，但它（似乎）有效。我正在使用XQuartz 2.7.7，这是撰写本文时的最新版本。