How does Mac OSX determine which dylib to load? - macos

I'm trying to run Apache in Mac OSX Yosemite using MacPorts' PHP (mod_php53.so). Note that I'm not using MacPorts' Apache but Yosemite's Apache with MacPorts' PHP. This was working fine with OSX Mavericks and Mountain Lion in the past.
I get this error when running /usr/sbin/apachectl -t in Yosemite:
httpd: Syntax error on line 228 of /private/etc/apache2/httpd.conf: Cannot load /opt/local/apache2/modules/mod_php53.so into server: dlopen(/opt/local/apache2/modules/mod_php53.so, 10): Library not loaded: /opt/local/lib/libaprutil-1.0.dylib\n Referenced from: /opt/local/apache2/modules/mod_php53.so\n Reason: Incompatible library version: mod_php53.so requires version 6.0.0 or later, but libaprutil-1.0.dylib provides version 4.0.0
In fact, /opt/local/lib/libaprutil-1.0.dylib current version is 6.4.0, so it should work.
otool -L /opt/local/lib/libaprutil-1.0.dylib
/opt/local/lib/libaprutil-1.0.dylib:
/opt/local/lib/libaprutil-1.0.dylib (compatibility version 6.0.0, current version 6.4.0)
I guess that Apache is loading the system's libaprutil-1.0.dylib located in /usr/lib:
otool -L /usr/lib/libaprutil-1.0.dylib
/usr/lib/libaprutil-1.0.dylib:
/usr/lib/libaprutil-1.0.dylib (compatibility version 4.0.0, current version 4.0.0)
This is confusing because the error message clearly states that MacPorts' libaprutil was not load because of version incompatibility but I guess it is trying to use the system's libaprutil and don't know how to force Apache to load MacPorts' libaprutil.
I already tried to set the DYLD_LIBRARY_PATH environment variable, but that did not help.
Any ideas?

This happens when the environment contains DYLD_LIBRARY_PATH=/usr/lib. Unset that and it should work.
Libraries are referenced using absolute paths on OS X. You correctly noticed /opt/local/apache2/modules/mod_php53.so references /opt/local/lib/libaprutil-1.0.dylib using its absolute path. However, in the presence of DYLD_LIBRARY_PATH the loader ignores the directory components and searches for the filename in the directories specified in DYLD_LIBRARY_PATH.
The error message you see is misleading: It is trying to tell you that an error occurred in the code that attempted to handle the /opt/local/lib/libaprutil-1.0.dylib load command (which was diverted due to the env variable).
Also, note that since MacPorts builds its PHP against MacPorts Apache, your PHP module is not necessarily binary-compatible to the system Apache. It might work for you, but that's only a coincidence.

Related

Tesseract Incompatible lib libpng16.16.dylib brew

dyld: Library not loaded: /usr/local/opt/libpng/lib/libpng16.16.dylib
Referenced from: /usr/local/opt/leptonica/lib/liblept.5.dylib
Reason: Incompatible library version: liblept.5.dylib requires version 54.0.0 or later, but libpng16.16.dylib provides version 29.0.0
Abort trap: 6
Have tried brew reinstall and upgrade, and tesseract reinstall, leptonica reinstall, deleted cache, deleted libs forcing new to be downloaded, nothing works. Not sure if this is a brew problem or leptonica, or the libpng thing. Is this a High Sierra gotcha? High Sierra libpng not compatible with whatever leptonica the same brew is installing? In which case that is brew's fault. Mac Port install leaves same error.
Something similar here, but no solution, note date is 2016 http://eeko-amaryllis.hatenablog.com/entry/2016/07/28/181303
google "liblept.5.dylib requires version" in quotes
gives you three results, the first being the above query, but the second is "Calling external command tesseract resulted in old version of ... " https://fr.mathworks.com/matlabcentral/answers/313225-calling-external-command-tesseract-resulted-in-old-version-of-tesseract-being-executed
the answer there refers to DYLD_LIBRARY_PATH
from terminal window
echo $DYLD_LIBRARY_PATH
/Applications/GIMP.app/Contents/Resources/lib:/Users/your_name_here/Downloads/magic/ImageMagick-7.0.7/lib/
You can check the libs for the offending older version of the dyld, but I knew I hadn't updated GIMP in a while and it wouldn't be surprising to find it used an imaging library. I did confirm by looking at that lib directory the lib was there, updated GIMP, checked ImageMagic wasn't using same lib, and still had to remove the DYD_LIBRARY_PATH reference as new GIMP didn't update it.

IDL fails due to wrong libfreetype.6.dylib version on MacOS when called from Matlab

This is another interesting version of a libfreetype.6.dylib version incompatibility. Having figured it out, I feel it is worth documenting ...
The setup is as follows:
MacOS 10.9.5
IDL 8.3
Matlab 2013b
Matlab is used to create a shell script on the fly which in turn will call an IDL .sav file. The shell script is then called via the unix() command in Matlab.
When running the generated shell script from the shell, all works fine. When trying to run it from Matlab via the unix() command, a libfreetype.6.dylib version issue appears:
dyld: Library not loaded: /opt/X11/lib/libfreetype.6.dylib
Incompatible library version: libidl.8.3.dylib requires version 15.0.0 or later, but libfreetype.6.dylib provides version 10.0.0
As has been stated in other posts on similar effects but with other applications, the error message is misleading as the program evidently never tries to actually load /opt/X11/lib/libfreetype.6.dylib
The version of /opt/X11/lib/libfreetype.6.dylib can be checked via the otool:
otool -L libfreetype.6.dyliblibfreetype.6.dylib:
/opt/X11/lib/libfreetype.6.dylib (compatibility version 18.0.0, current version 18.2.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1)
Obviously the version provided by X11 is higher than what is required by IDL.
To fix this just copy /opt/X11/lib/libfreetype.6.dylib into /Applications/exelis/idl83/bin/bin.darwin.x86_64
Note: the libfreetype.6.dylib does not exist in the IDL application file hierarchy at all, so, presumably, some linking with the X11 provided library version must go wrong ... fixing that would probably be a cleaner solution.

Git doesn't work after a clean installation using macports due to libcurl.4.dylib version?

I have a Mac OSX Lion 10.7.5 and the latest macports version 2.3.1. After successfully installing git I get the following error trying to clone a repository:
/Users/bravegag/code$ git --version
git version 2.1.2
/Users/bravegag/code$ git clone http://github.com/MTG/sms-tools.git
Cloning into 'sms-tools'...
dyld: Library not loaded: /opt/local/lib/libcurl.4.dylib
Referenced from: /opt/local/libexec/git-core/git-remote-http
Reason: Incompatible library version: git-remote-http requires version 8.0.0 or later, but libcurl.4.dylib provides version 7.0.0
Can anyone explain why this happens and how to fix it?
Make sure you don't have DYLD_LIBRARY_PATH set. It is generally not necessary on OS X and only useful for development. If you need it for a tool, you should contact the tool author to get their linking fixed, because libraries are usually referenced using absolute paths on OS X.

I can't run Qt app on other mac

I make a simple Qt app on mac with Qt 5.1. I deploy it by using macdeployqt but when I run it on other mac.
I run otool -L with my app and It says
/Users/aratn0n/Qt//5.1.0/clang_64/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.1.0, current version 5.1.0)
/Users/aratn0n/Qt//5.1.0/clang_64/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.1.0, current version 5.1.0)
/Users/aratn0n/Qt//5.1.0/clang_64/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.1.0, current version 5.1.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
It seems it uses the library from my machine so when I run it on other machine it can't use the Qt library in the Frameworks folder within the app bundle.
How can I fix it?
I currently don't have a solution, but I ran into the same issue that you had when running macdeployqt. Based on another post, the reason why macdeployqt does not change the paths to local frameworks (#executable_path/../Frameworks/...) is because of the double slash in the paths of the Qt libraries. You need to manually run install_name_tool to correct the double slashes
install_name_tool -change /Users/<USERNAME>/Qt5.1.0//5.1.0/clang_64/lib/QtQuick.framework/Versions/5/QtQuick /Users/<USERNAME>/Qt5.1.0/5.1.0/clang_64/lib/QtQuick.framework/Versions/5/QtQuick <EXECUTABLE>
Sorry I can't help anymore, but this is as far as I've got to deploying my app on Mac OS X. Unfortunately for me, when I remove/rename my installed Qt library, my app no longer works because it can't find the libraries set up by macdeployqt.
if you intend to use qt as a dynamic library then you will have to distribute the dylib...
it is much simpler to use it as a static library. also you don't gain much from having a shared library if you aren't sharing it, so if you just have one process, build qt as a static lib and link it against your product, then there won't be a runtime dependency on an external lib.
It appears that macdeployqt hasn't done its job.
It should copy the required Qt libraries into the app bundle and set the paths for you.
Either look into why it's failing, or copy the files yourself and update the paths with install_name_tool
It's a bug in the installation of Qt that stops macdeployqt running properly in 5.1.0 as mentioned in the answer by user kimbaudi.
It has been fixed in 5.1.1.
If for some reason you must use 5.1.0 then run macdeployqt and you will find the Qt frameworks have been copied to the bundle.
You will then need to cd to the Frameworks directory in the bundle and rewrite the link path via commands of the form
install_name_tool -change /Users/username/Source/Qt5//5.1.0/clang_64/lib/QtGui.framework/Versions/5/QtGui #executable_path/../Frameworks/QtGui.framework/Versions/5/QtGui QtCore
You'll need to do it for every Qt framework to rewrite the dependencies on each other and also all the dylibs in the PlugIns directory as well as the executable.

I messed up my terminal environment on Mac OS X and was wondering how to fix it

When I open a terminal window this is what I get immediately:
dyld: Library not loaded: /usr/lib/libiconv.2.dylib
Referenced from: /bin/bash
Reason: Incompatible library version: bash requires version 7.0.0 or later, but libiconv.2.dylib provides version 6.0.0
[Process completed]
You could try removing the files ~/.bash_profile, ~/.profile, ~/.bashrc, and ~/Library/Preferences/com.apple.Terminal.plist, if they exist, but most likely this is actually the problem as described by the error: libiconv got replaced with an older version. In this case, there are two methods to replace it: download the source code, build and install by ssh-ing into the computer, or reinstall the library from your installer DVD. If you choose to install from the DVD, I would suggest downloading Pacifist so that you can install just libiconv instead of the whole system (of course, there might be other files that need replacing too).

Resources