OSX MySQL DYLD_LIBRARY_PATH libmysqlclient.18.dylib – fix

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>
import MySQLdb

File “/Library/Frameworks/Python.framework/Versions/2.7/lib/
python2.7/site-packages/MySQLdb/__init__.py”, line 19, in <module>
import _mysql

ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/
python2.7/site-packages/_mysql.so, 2): Library not loaded: libmysqlclient.18.dylib

Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/
python2.7/site-packages/_mysql.so

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:

export DYLD_LIBRARY_PATH=/usr/local/mysql/lib

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:

si@home:~$ su
dyld: DYLD_ environment variables being ignored because main executable…
(/usr/bin/su) is setuid or setgid
Password:

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?

Do this:

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]

related

  • No Related Posts

September 7th, 2013 | Bugs |
  • Amir Boziev

    Worked for me. Thank you so much!

  • Ahh brilliant. Yeah, that was a massive pain in the ass until I figured that out.

  • Gary Allen Vollink

    Notes: 1) DYLD_FALLBACK_LIBRARY_PATH is the “standard recommendation” for many reasons. Check man dyld for info. I wouldn’t want anybody to think that shortcutting this without _FALLBACK is a good thing. 2) For anybody who DOES mess with either DYLD_FALLBACK_LIBRARY PATH _OR_ DYLD_LIBRARY_PATH, if you later decide to do the soft-link variation (which has many advantages), it will ONLY work if DYLD**PATH has never been set in your shell. Even they are not set, if they are explicitly UNSET, the behavior will not include any defaults. (Clean your .bash_profile, .bashrc, etc — log out — log back in).

  • Ahh, excellent suggestions. Thank you so much.

    There’s definitely a world of subtlety around this stuff.

    I’m surprised with the huge amount of searching I did that I didn’t find the DYLD_FALLBACK_LIBRARY_PATH suggestion. Very surprised. Still, it’s here now, so I have it on record (in case I need it again) – and for that I thank you.

  • Gary Allen Vollink

    I /ALSO/ got around to testing (as from man dyld) that /usr/local/lib is ALSO a default fallback, and works as expected, so doing the softlink to that location is more “upgrade safe” than the links straight into /usr/lib.

    Next on /my/ list is figuring out if there’s a way to make ‘mac ports’ project install directly to /usr/local instead of /opt/local.

  • So it’d be better to do the above soft link into /usr/local/lib, rather than /usr/lib ?

    If so, I’ll update the above post.

    I admit I’m at the edge of my knowledge re how the insides of these libraries and systems all interface. Mostly the above solution is “this worked without anything apparently breaking” rather than based on any deep technical understanding.

  • Gary Allen Vollink

    Honestly, I’m happy to see someone willing to talk about it (as opposed to 6 year old abandoned posts) and have readable comments, because even down here it helps people find and decide the best answer for themselves (which is really what we all want – information enough to decide for ourselves). [ so maybe just point folks down here to the comments? ]

    I have 20 years of UNIX development and admin experience, but I’m VERY new to Mac (which has it’s odd points), and I always try to leave any place in better shape than I found it.

  • *nod* cool. I’ve been around (Linux mostly) for about the same length of time – but only really adminning as little as I possibly could to to get my coding work done :)

    Thanks for your feedback Gary – that’s super helpful. I’ve updated the post to reflect your advice.

  • Paul James

    You saved my life! …well, my sanity at least :)

  • Ahh, I know EXACTLY what you mean (hence the post). Super glad it helped!