# Fixing Gnuplot on OS X 10.7.3

Last night I was analyzing a fixed-ended beam with variable cross-section—as you do—and when I got done, I wanted to plot up some of the solutions. So I fired up Gnuplot and…

$gnuplot dyld: Library not loaded: /usr/X11/lib/libfreetype.6.dylib Referenced from: /usr/X11/lib/libfontconfig.1.dylib Reason: Incompatible library version: libfontconfig.1.dylib requires version 14.0.0 or later, but libfreetype.6.dylib provides version 13.0.0 /Users/drdrang/bin/gnuplot: line 71: 36072 Trace/BPT trap: 5 GNUTERM="${GNUTERM}"
GNUPLOT_HOME="${GNUPLOT_HOME}" PATH="${PATH}" DYLD_LIBRARY_PATH="${DYLD_LIBRARY_PATH}" HOME="${HOME}" GNUHELP="${GNUHELP}" DYLD_FRAMEWORK_PATH="${DYLD_FRAMEWORK_PATH}"
GNUPLOT_PS_DIR="${GNUPLOT_PS_DIR}" DISPLAY="${DISPLAY}"
GNUPLOT_DRIVER_DIR="${GNUPLOT_DRIVER_DIR}" "${ROOT}/bin/gnuplot-4.4.3" "$@"  Uh-oh. I think 10.7.3 broke my installation of Gnuplot. — Dr. Drang (@drdrang) Wed Feb 8 2012 The Gnuplot I use is a precompiled version that comes from the Octave-Forge project.1 As you might expect from the name, this project’s main concern is providing a precompiled version of Octave—it’s the version of Octave I use—along with several Octave libraries. But because Octave has some hooks into Gnuplot, the Octave-Forge distribution for the Mac includes Gnuplot, too. You may look down your nose at precompiled versions of open source software. “Real hackers compile from source,” and all that. But honestly, Gnuplot is really hard to compile from source, especially if you want to include certain features, like PNG and PDF support. The more features you want, the longer the library dependency chain gets, and it’s almost impossible to compile every one of those libraries on a Mac without one of them failing and breaking the chain. I’ve never been able to compile Gnuplot on a Mac with the features I want. Against my better judgement, I tried installing it through Homebrew: brew install gnuplot  This, of course, also requires the installation of a chain of dependencies. I’m not sure how many packages Homebrew would’ve installed before getting to Gnuplot, but it failed after the second or third, and I decided to call it a night. This morning, after noting that Gnuplot was broken on the iMac in my office, too, I poked around on the Octave-Forge mailing list to see if there was anything written about this problem and immediately came upon this thread started by Gabi Huiber, who had run into the same problem I had and was also blaming the recent Lion upgrade. He was being helped by Alexander Hansen, who, at the time, didn’t think the 10.7.3 upgrade was related. I subscribed to the list and was about to write in support of Gabi’s interpretation when a new message from Alexander appeared in my inbox with the solution. If you want an explanation of why the problem developed, you should read Alexander’s message in the thread. I’ll just say that it did arise from the 10.7.3 upgrade and has to do with a conflict between a couple of updated libraries that came with 10.7.3 and the libraries that come with the precompiled Gnuplot. Beyond that vague description my understanding fades rapidly. The solution, though, is easy to understand and easy to implement: 1. Open /Applications/Gnuplot.app/Contents/Resources/bin/gnuplot in your favorite text editor. This is a shell script that sets up several environment variables and runs the Gnuplot binary. 2. Find all instances of DYLD_LIBRARY_PATH in that script and replace them with DYLD_FALLBACK_LIBRARY_PATH. 3. Save the edited script. Thanks to Gabi for initiating the thread and especially to Alexander for coming up with the solution. I’ve looked at other plotting solutions, but have always come back to Gnuplot because of its flexibility and the control I have over its output. The prospect of not being able to use it—even if only for a few weeks until a new precompiled version was built—made me nervous. 1. If you look in the error message, you’ll see a reference to /Users/drdrang/bin/gnuplot, which you might think is some weird script I whipped up on my own. It isn’t. It’s just a symlink to an executable that’s part of the precompiled distribution. I made that link so I wouldn’t have to add another directory to my $PATH