Is it OK to use DYLD_LIBRARY_PATH on Mac OS X? And, what’s the dynamic library search

[prosseek]

I read some articles discouraging of the use of DYLD_LIBRARY_PATH, as the the path of dynamic library should be fixed using -install_name, @rpath, and @loader_path.

In terms of making a program that runs both on Linux and Mac OS X, DYLD_LIBRARY_PATH of Mac OS X does exactly what LD_LIBRARY_PATH of Linux. And, we can share (almost) the same make file that doesn't have the -install_name and @rpath.

* Is this OK to use DYLD_LIBRARY_PATH on Mac OS X?
* What's the dynamic library search algorithm with Mac OS X when the binary can't find the dynamic library? current directory -> DYLD_LIBRARY_PATH directories ... ?

[Detrius]

Try this on your Mac: echo $DYLD_LIBRARY_PATH

It's an undefined variable.


So far as I'm aware, OS X does NOT have a dynamic library search algorithm. 'otool -L' on a binary shows you where it expects its libraries to be. If they aren't there, the binary fails to load.

Example:

[blackie:/Applications/VLC.app/Contents/MacOS] (0) whschultz% otool -L VLC
VLC:
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.19.0)
	@loader_path/lib/libvlc.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	@loader_path/lib/libvlccore.4.dylib (compatibility version 5.0.0, current version 5.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
	@loader_path/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

Those @loader_path libraries are expected to be in exactly that path relative to the loading binary. If you move them--relatively--the app will fail to launch.

You can still use the same Makefile on Mac and Linux. You'll just need to make sure that the install name of your libraries is correct and that it matches where the libraries are installed.

This is where the .app bundles come in handy. You can put all of your libraries inside the .app bundle, and they'll never move--relative to the launching binary. Additionally, you'll never have to worry about the wrong version of a library being installed.

[chown33]

Originally Posted by Detrius

So far as I'm aware, OS X does NOT have a dynamic library search algorithm.

man dyld

Originally Posted by prosseek

I read some articles discouraging of the use of DYLD_LIBRARY_PATH,

Which articles? Be specific.

In terms of making a program that runs both on Linux and Mac OS X, DYLD_LIBRARY_PATH of Mac OS X does exactly what LD_LIBRARY_PATH of Linux. And, we can share (almost) the same make file that doesn't have the -install_name and @rpath.

Then it shouldn't be that hard to change the makefile to provide the full set of options for the Mac OS X build. There are shortcuts and there are too many shortcuts. This sounds like the latter.

If you need help changing the makefile, post it here and ask for help.

* Is this OK to use DYLD_LIBRARY_PATH on Mac OS X?

It depends on what you mean by "OK".

Reliance on DYLD_LIBRARY_PATH is a security risk. It can be used to inject libraries into the runtime of other code, without altering the targeted code.

Consequently, there are situations when DYLD_LIBRARY_PATH (and other DYLD* values) are not used by the dyloader, in order to maintain security. If you require DYLD_LIBRARY_PATH, and the context of the execution forbids it, then your code won't run.

Knowing nothing else about your program, it's impossible to guess if these scenarios are OK or not.

* What's the dynamic library search algorithm with Mac OS X when the binary can't find the dynamic library? current directory -> DYLD_LIBRARY_PATH directories ... ?

man dyld