MQTT Dynamic Library Not Found on Mac OS X

Great article on how to fix your dynamic library linking:

http://qin.laya.com/tech_coding_help/dylib_linking.html

As it turns out, in OS X 10.0 – 10.2, you need the path to the library to show up in there — what you need is for the second line to show something like this:

@executable_path/../Frameworks/libbz2.1.0.2.dylib (compatibility version 1.0.0, current version 1.0.2)

This tells OS X that it should look in the place where the binary is, move up a directory and into the Framworks folder, and the library will be sitting there. Which it is. Indeed, if you run otool -L on the binary of some application in your /Applications folder that has a working frameworks or dylibs in the app package Frameworks folder (try one of the applications from Omni), you can see that this is the case — all of their binaries comtain the right path. But the compiler is not figuring things out right… In fact, as it is right now, you can place the dylib in the same folder that the .app package is in, and things will run properly. But that’s not what we want.

Well, the first thing you can try to do is to use install_name_tool. If you read the man page for install_name_tool, you can actually change the information inside of the executable so that it has the right location. Depending on how the application was compiled, this may or may not work correctly. More specifically, you’ll be able to change the location if there was extra space compiled into the binary to allow space for a longer pathname. Generally install_name_tool will work on binaries, but not libaries. So you can now do this:

% install_name_tool -change libbz2.1.0.2.dylib
 @executable_path/../Frameworks/libbz2.1.0.2.dylib MyFunBinary 

Now try to run the file. Voila! It should work.
However this is somewhat unacceptable, as whenever the binary gets changed — taht is, whenever you recompile your code, this binary is going to get the short end of the shaft and get replaced by a new binary. Now, you could actually set up a shell script that runs install_name_tool every time you build your program, but that’s somewhat of a hack. We might as well try to fix things at the origin of the problem.

Whole article linked here: http://qin.laya.com/tech_coding_help/dylib_linking.html