因此，我们都知道Mountain Lion不再提供X11，需要X11的用户可以下载Xquartz。 Xquartz安装到/opt，但它也将X11和X11R6符号链接到/usr。但是当构建需要链接到X11包含文件的软件时，我发现我必须传递一个环境变量，将/usr/X11/include（或/opt/X11/include）添加到库搜索路径以获取./configure找到X11库。我的问题是为什么？
我已经对Google做了一些研究（很多结果都指向Stack Overflow），我已经阅读了Apple的文档，这些来源都表明OS X中没有与/etc/ld.so.conf文件相同的内容在许多（如果不是全部）Linux发行版中找到。 Apple甚至声称DYLD_LIBRARY_PATH默认为空。但是，在Lion下（安装了Apple的最后一个'官方'X11），相同的./configure脚本会找到X11库而不向库搜索路径添加任何内容。
那么，为什么不能./configure脚本在没有明确修改库搜索路径的情况下在Mountain Lion中找到X11库？
答案 0 :(得分：1)
一年多前被问过......但是当我带着类似的问题来到这里时......
请注意，在提到的ruby问题中，没有修改库搜索路径。 该解决方案只是设置了一个环境变量，许多Makefile将其作为C ++编译器的标志。该示例定义了构建时间-I ncludepath ，即在哪里搜索.h eaders - 而不是库（这可能是 - L选项到您的编译器/链接器）。两者都是构建时间选项。 是否LD_LIBRARY_PATH或DYLD_LIBRARY_PATH - 都是运行时中动态链接器考虑的环境变量。 （有关更多信息，请参阅http://en.wikipedia.org/wiki/Dynamic_linker）
我手头没有10.8之前的机器，但猜测可能有一个符号链接 / usr / include / X11 - ＆gt; / opt / X11 / include / X11 - 否则我不知道如何 假设相同的来源，它本来可以工作......
这是解决此类问题的另一个潜在解决方案（只修复了我的realvnc构建）：
$ autoconf
$ ./configure
所以你的问题是“为什么？”最终可以回答：因为你的源代码包含一个“预构建”的配置脚本，该脚本基于不包含的旧的autotools / opt / X11 /包含作为搜索X11的潜在位置包括或者根本没有在您当前的系统上获得上面提到的一些编译时标志。 我通过自制软件安装了autoconf - 啊，好东西，欢呼。