macOS 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]

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

man dyld

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

 

[sswam]

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

I am porting my game Rescue from Linux to the Mac (and Windows), and I am including several shared libraries with the game. I wanted the dynamic linker to look in the same directory for the libraries.

Setting DYLD_LIBRARY_PATH=. or the full path to the directory is one option, and it works. There's no security issue with running my game. The only minor issue is that you need a wrapper shell script or such to set the environment variable.

As an alternative, we can modify the executable and the libraries to remove absolute paths, just keeping the basename. I used a shell script like this:

lib_path_to_rm=/Users/sam/inst/lib/
for bin in *.dylib rescue-exe; do
  otool -L $bin | tr -d '\t' | sed 's/ .*//' | grep "^$lib_path_to_rm" |
  while read A; do install_name_tool -change $A `basename $A` $bin; done
done

for bin in *.dylib; do
  otool -D $bin | grep "^$lib_path_to_rm" |
  while read B; do install_name_tool -id `basename $B` $bin; done
done

Or you can possibly build the libraries and executables with just the basenames for libraries instead of absolute paths. I'm not sure how to do that.

All this nonsense makes me think I should have used static linking! or read the manual, or something.

 

[AzN1337c0d3r]

Is it not possible to build static versions of these libraries that you use in your game? I find due to issues like these, the advantages of dynamic libraries are often not worth their trouble.

Also, have a look at rpath

 

[sswam]

Is it not possible to build static versions of these libraries that you use in your game?

Yeah I should try it with static linking. Some libraries don't work correctly with static linking, e.g. Linux libc. But for the libraries I'm using, SDL and such, it should work okay. I can't and wouldn't want to statically link the system libraries or opengl, so it needs a tricky command line.

There's also a legeal issue, I'm using SDL1.2 which is LGPL licensed. It says "a statically linked library is allowed if either source code or linkable object files are provided". So I'd have to include those.

I'll ask some other game devs how they do it.

I found this post from Ryan Gordon, an SDL developer, explaining why they prefer that we dynamically link SDL https://plus.google.com/+RyanGordon/posts/TB8UfnDYu4U

 

[mrichmon]

You could consider explicitly loading the libraries from your game code.

The system call is "dlopen".

 

[sswam]

You could consider explicitly loading the libraries from your game code.

The system call is "dlopen".

Hell, no.

But thanks for the suggestion.

 

[Madd the Sane]

SDL 1.2 had its license changed to the zlib license. SDL2 also uses the zlib license.

Also, rpath is a good idea. Also see install_name_tool, which can change the load paths of libraries.

 

[sswam]

SDL 1.2 had its license changed to the zlib license. SDL2 also uses the zlib license.

I don't think SDL1.2 is zlib, it says LGPL here on the SDL website and also in the source code archives. https://www.libsdl.org/license.php I should just use SDL2.0 anyway. But the SDL devs still recommend to use dynamic linking rather than static linking (so that it's possible to upgrade the version of SDL used without relinking).

 

[Madd the Sane]

I don't think SDL1.2 is zlib, it says LGPL here on the SDL website and also in the source code archives. https://www.libsdl.org/license.php I should just use SDL2.0 anyway. But the SDL devs still recommend to use dynamic linking rather than static linking (so that it's possible to upgrade the version of SDL used without relinking).

My bad.
I guess I was thinking of only SDL2. Although SDL2 is capable of dynamically loading a newer version of SDL2 if it can find it. I think it knows about Steam, but other than that, I don't know.