Running Komodo Edit (or IDE) on OSX, with some of the recent (10.8.5) system updates, you can get this delightful error message:
Image not found
With an error report containing:
dyld: Library not loaded: @executable_path/../Python
Referenced from: /Applications/Komodo Edit 8.app/Contents/MacOS/mozpython
Reason: image not found
Mashed in between a page of incomprehensible gibberish.
What does this mean? Oh, it’s just being a bit stupid, and lost track of where its own bits and pieces are. Ie, the mozpython embedded in Komodo can’t find the Komodo Python interpreter. “Help help I can’t find the forest, all these stupid trees are in the way!” Etc.
One side effect is it stops you being able to navigate to a function definition – which is a little annoying.
Until they roll out an updated version of Komodo, a short term fix is:
sudo install_name_tool -change “@executable_path/../Python” “@executable_path/../Frameworks/Python.framework/Python” “/Applications/Komodo Edit 8.app/Contents/MacOS/mozpython”
Note you’ll need to change “Edit” to “IDE” above if you’re using the IDE version of Komodo.
You can do this without restarting Komodo. Searching for a definition will then spin its wheels for a while, reorganising its brain, then after that everything will (should) be hunky dory again.
For some reason, the OSX version of MySQL can’t find its own libraries.
If you’re trying to connect to MySQL from code (in this case, Python, and the MySQLdb library), you’ll typically see something like this:
Traceback (most recent call last):
File “demo.py”, line 3, in <module>
python2.7/site-packages/MySQLdb/__init__.py”, line 19, in <module>
python2.7/site-packages/_mysql.so, 2): Library not loaded: libmysqlclient.18.dylib
Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/
Reason: image not found
Which basically translates to “Duh, I can’t find myself.”
Specifically, it’s looking for the file libmysqlclient.18.dylib in /usr/lib, and not finding it – why? Because it installed it in /usr/local/mysql/lib. It’s been broken a few years.
Yay open source!
Anyway, there are several fixes out there, with varying levels of crapness.
The standard recommendation is to put this in your .bashrc (or .bash_profile) in your home dir:
Which fixes the problem, except then every time you try to run anything that isn’t MySQL related from the command line, you get a stupid message like this:
dyld: DYLD_ environment variables being ignored because main executable…
(/usr/bin/su) is setuid or setgid
This gets old and boring verrrrry quickly.
Another suggestion is to put the export statement at the start of any script that uses MySQL, followed by an equivalent unset command at the end (so you’re not polluting the environment).
Now, have a quick think about how many different places you’d have to put this in (ie, any script or code that connects, accesses or uses any code at all that talks to MySQL). BORING.
After I’d edited 5 or 6 scripts I decided “ok, this is crap, there must be a better way.”
So, what’s the cleanest solution? Specifically, one that avoids having to alter everything you ever write, just to get around a (hopefully soon fixed) bug in the MySQL installation?
sudo ln -s /usr/local/mysql/lib/libmysqlclient.18.dylib /usr/lib/libmysqlclient.18.dylib
In other words, create a link from /usr/local/mysql/lib (actual location) to /usr/lib (the place MySQL goes looking).
No coding around the bug, no spurious and/or dangerous environment variables. Simple, clean, with minimal or zero side effects.
[update: It’s been further suggested, by Gary Allen Vollink, below, that linking to /usr/local/lib might be more upgrade friendly – and thus safer – than /usr/lib. Please read his comments. I’m inclined to agree]