Why doesn't OS X 10.8 Mountain Lion find the X11 library when creating software?

Question

So, we all know that Mountain Lion is no longer shipped with X11, and users who need X11 are encouraged to download Xquartz. Xquartz is installed on /opt , but also symbolizes X11 and X11R6 before /usr . But when creating software that requires binding to X11, include the files, I found that I had to pass the environment variable by adding /usr/X11/include (or /opt/X11/include ) in the library search path to get ./configure to find the X11 libraries. My question is why?

I did some research on Google (many results indicate a stack overflow) and I read the Apple documentation and all these sources indicate that there is no equivalent in OS X in the /etc/ld.so.conf file found in many (if not all) Linux distributions. Apple even claims that DYLD_LIBRARY_PATH is empty by default. However, under Lion (with Apple installed the "official" X11), the same ./configure scripts will find the X11 libraries without adding anything to the library search path.

So, why ./configure scripts cannot find X11 libraries in Mountain Lion without explicitly modifying the library search path?

Answer 1

They answered the question more than a year ago ... but since I came here with a similar problem ...

Please note that the library search path was not changed in the mentioned ruby ​​question. This solution simply set the environment variable that many Makefiles chose as flags for the C ++ compiler. This example determined the build time of -I ncludepath, i.e. where to look for .h eaders - not libraries (which would be the -L option for your compiler / linker). Both options would be build time. LD_LIBRARY_PATH or DYLD_LIBRARY_PATH - both are environment variables that are considered by the dynamic linker at runtime. (For more details see http://en.wikipedia.org/wiki/Dynamic_linker )

I don’t have a machine up to 10.8 on hand, but guess that there might have been a symbolic link / usr / include / X 11 → / opt / X11 / include / X11 - otherwise I have no idea how it could work before taking the same sources ...

This is another potential solution for such tasks (it just fixed my build of realvnc):

 $ autoconf $ ./configure 

So your question is "why?" might ultimately be the answer: since your sources contained a “pre-configured” configure script that was based on older startups that did not include / opt / X 11 / include as a potential place to search, X11 includes or simply didn't get some of the above compile time flags directly on your current system. I have autoconf installed via homebrew - ahh, great stuff, greetings.