6

So, we all know that Mountain Lion doesn't ship with X11 anymore and users needing X11 are directed to download Xquartz. Xquartz installs to /opt, but it also symlinks X11 and X11R6 to /usr. But when building software that requires linking to X11 include files, I've discovered that I must pass an environment variable adding /usr/X11/include (or /opt/X11/include) to the library search path to get ./configure to find the X11 libraries. My question is why?

I've done some research on Google (many results pointing back to Stack Overflow), and I've read Apple's documentation, and these sources all indicate that there is no equivalent in OS X to the /etc/ld.so.conf file found in many (if not all) Linux distributions. Apple even states that DYLD_LIBRARY_PATH is empty by default. However, under Lion (with Apple's last 'official' X11 installed), the same ./configure scripts would find the X11 libraries without adding anything to the library search path.

So, why can't ./configure scripts find X11 libraries in Mountain Lion without explicit modification of the library search path?

Chip Warden
  • 61
  • 1
  • 4
  • What's an example of an X11 app you are trying to configure ... and the output of configure? If I download [xpdf](http://www.foolabs.com/xpdf/), for example, it is finding my X libs on Mountain Lion and I don't think I've done anything special (aside from installing XQuartz). – Stennie Jul 30 '12 at 01:28
  • Specifically, Ruby 1.8.7. You can see the issue and solution here: http://stackoverflow.com/questions/11664835/mountain-lion-rvm-install-1-8-7-x11-error As I said in the original question, I have "fixed" the problem. I just was wondering if anyone knows why this behavior is different in Mountain Lion with Xquartz as opposed to Lion with Apple X11. – Chip Warden Jul 30 '12 at 04:32

1 Answers1

1

Asked more than a year ago... but as I came here with a similar problem...

Note that in the mentioned ruby question, there was no library search path being modified. That solution just set an environment variable that is picked up by many Makefiles as the flags for the C++ compiler. That example defined the build time -I ncludepath, i.e. where to search for .h eaders -- not libraries (which would have been a -L option to your compiler/linker). Both would have been build time options. Whether LD_LIBRARY_PATH or DYLD_LIBRARY_PATH -- both are environment variables that are considered by the dynamic linker at runtime. (For more, see http://en.wikipedia.org/wiki/Dynamic_linker )

I have no pre-10.8 machine at hand, but guess that there might have been a symlink /usr/include/X11 -> /opt/X11/include/X11 -- otherwise I have no Idea atm how it could have worked before, assuming same sources...

This is another potential solution for such problems (just fixed my realvnc build):

$ autoconf
$ ./configure

So your question for "why?" could be eventually answered with: Because your sources contained a 'pre-built' configure script that was based on older autotools that did not include /opt/X11/include as a potential location to search for X11 includes or simply did not get some of the above mentioned compile time flags right on your current system. I have autoconf installed through homebrew -- ahh, great stuff, cheers.

user44958
  • 31
  • 2