Another OS X hurdle for Unix geeks: In OS X, there’s no such thing as a dynamic linker search path.
Every library has its full pathname compiled into it.
This means that for all practical intents, you have to compile a library for correct path. No relocation. You compile a library for /usr/lib, you cannot install it in /opt/lib. This is mildly irritating. If you compile a library for /usr/lib, and install it in /opt/lib, and then link a program against this library, the link editor will cheerfully link the program against the library in /opt/lib. It’s only when you try to run it that you’ll realize that the dynamic linker is looking for the library in /usr/lib. Oups.
There’s two ways around this problem, but none is entirely satisfactory.
The pathname compiled into the library can be relative to the path of the executable that’s linked against it. This allows for libraries belonging to one package residing in
You can also specify the actual pathname of a library using the -dylib_file flag for the compiler. This is roughly similar to the -R linker flag under Linux or Solaris, or -rpath under Irix. But in difference to Linux or Solaris, the -dylib_file flag doesn’t specify a search path (remember, there’s no such thing as a dynamic linker search path in OS X); it rather specifies the full pathname of the library. You also have to specify the intended (compiled-in) pathname of the library as a second argument to -dylib_file.
Well, it’s not quite true that the dynamic linker doesn’t have a search path. You can set the environment variable DYLD_LIBRARY_PATH (similar to LD_LIBRARY_PATH) to specify a search path.
So in the end, it’s just like every other version of Unix: The dynamic linker doesn’t find your libraries, you give up after a few tries, sigh, and set DYLD_LIBRARY_PATH. Same procedure as last year.
No comments yet.
Leave a comment
Sorry, the comment form is closed at this time.