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

Discussion in 'Mac Programming' started by prosseek, Jun 30, 2010.

  1. macrumors newbie

    Joined:
    Jun 30, 2010
    #1
    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 ... ?
     
  2. macrumors 68000

    Joined:
    Sep 10, 2008
    Location:
    Asheville, NC
    #2
    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.
     
  3. macrumors 603

    Joined:
    Aug 9, 2009
    #3
    man dyld


    Which articles? Be specific.

    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.

    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.


    man dyld
     
  4. sswam, Sep 2, 2014
    Last edited: Sep 3, 2014

    macrumors newbie

    sswam

    Joined:
    Sep 2, 2014
    #4
    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.
     
  5. macrumors 6502

    Joined:
    Sep 13, 2010
    #5
    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
     
  6. sswam, Sep 3, 2014
    Last edited: Sep 3, 2014

    macrumors newbie

    sswam

    Joined:
    Sep 2, 2014
    #6
    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
     
  7. macrumors 6502a

    Joined:
    Jun 17, 2003
    #7
    You could consider explicitly loading the libraries from your game code.

    The system call is "dlopen".
     
  8. macrumors newbie

    sswam

    Joined:
    Sep 2, 2014
    #8
    Hell, no.

    But thanks for the suggestion.
     
  9. macrumors 6502

    Madd the Sane

    Joined:
    Nov 8, 2010
    Location:
    Utah
    #9
    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.
     
  10. macrumors newbie

    sswam

    Joined:
    Sep 2, 2014
    #10
    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).
     
  11. macrumors 6502

    Madd the Sane

    Joined:
    Nov 8, 2010
    Location:
    Utah
    #11
    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.
     

Share This Page