Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

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

P

prosseek

macrumors newbie
Original poster
Jun 30, 2010
1
0
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 ... ?
 
D

Detrius

macrumors 68000
Sep 10, 2008
1,623
19
Apex, NC
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:

Code: 
[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

chown33

Moderator
Staff member
Aug 9, 2009
10,739
8,415
A sea of green
Detrius said:
So far as I'm aware, OS X does NOT have a dynamic library search algorithm.
Click to expand...

man dyld


prosseek said:
I read some articles discouraging of the use of DYLD_LIBRARY_PATH,
Click to expand...
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.
Click to expand...
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?
Click to expand...
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 ... ?
Click to expand...
man dyld
 
sswam

sswam

macrumors newbie
Sep 2, 2014
4
0
prosseek said:
* Is this OK to use DYLD_LIBRARY_PATH on Mac OS X?
Click to expand...

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:

Code: 
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.
 
Last edited:
A

AzN1337c0d3r

macrumors 6502
Sep 13, 2010
448
2
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

sswam

macrumors newbie
Sep 2, 2014
4
0
AzN1337c0d3r said:
Is it not possible to build static versions of these libraries that you use in your game?
Click to expand...

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
 
Last edited:
M

mrichmon

macrumors 6502a
Jun 17, 2003
873
3
You could consider explicitly loading the libraries from your game code.

The system call is "dlopen".
 
Madd the Sane

Madd the Sane

macrumors 6502a
Nov 8, 2010
534
73
Utah
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

sswam

macrumors newbie
Sep 2, 2014
4
0
Madd the Sane said:
SDL 1.2 had its license changed to the zlib license. SDL2 also uses the zlib license.
Click to expand...

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

Madd the Sane

macrumors 6502a
Nov 8, 2010
534
73
Utah
sswam said:
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).
Click to expand...

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.
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom