DYLD_LIBRARY_PATH messes up applications

Question

Level 1

65 points

DYLD_LIBRARY_PATH messes up applications

Hi all,

i've got a strange problem with some libs i installed from MacPorts and the environment variable DYLD LIBRARYPATH ...

First of all, i'm not sure whether this is the right forum to ask this, so if there is any better forum / newsgroup, please let me know.

The problem is the following.

I installed the TIFF library via MacPorts, because it is needed by some other software that i want to compile. (FYI: that other software uses the good old 'configure; make; make install' - triad.)

In order for that other software to find the libs when i run it, i need to set the environment variable DYLD LIBRARYPATH to something like "/opt/local/lib:..." (I think)

However, when i put that in my .cshrc, and then run, for instance, 'opendiff' i get the strange error message:

dyld: lazy symbol binding failed: Symbol not found: _cgTIFFSetErrorHandler

Referenced from: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ ImageIO.framework/Versions/A/ImageIO

Expected in: /opt/local/lib/libTIFF.dylib

The strange thing is that there is no libTIFF.dylib in /opt/local/lib!

There are just these:

% ls libtiff*

libtiff.3.dylib* libtiff.dylib@ libtiffxx.3.dylib* libtiffxx.dylib@

libtiff.a libtiff.la* libtiffxx.a libtiffxx.la*

I also don't get why it expects libTIFF to be in /opt/local/lib ?

Now, i could manually set and unset DYLD LIBRARYPATH whenever i run that other software or a built-in app, resp., but that is, of course, very cumbersome.

Does anyone have an idea?

Could some kind soul please shed some light on this strange behavior?

Should i be using DYLD FALLBACK_LIBRARYPATH??

I've reviewed the man page of dyld, but it is not quite clear to me.

(I'm coming from a unix world, so this DYLD LIBRARYPATH business is not quite familiar yet.)

Thanks a lot in advance.

Best regards,

Gabriel.

MacBook Pro, Mac OS X (10.4.10)

Posted on Aug 31, 2007 3:19 AM

Reply

Answer 1

etresoft

Level 8

46,134 points

Aug 31, 2007 6:13 AM in response to GabrielZ

GabrielZ wrote:
Hi all,

i've got a strange problem with some libs i installed from MacPorts and the environment variable DYLD LIBRARYPATH ...

DYLD LIBRARYPATH is the same as the traditional Unix LD LIBRARYPATH. You don't have to set it, just append new paths to it using a colon.

In order for that other software to find the libs when i run it, i need to set the environment variable DYLD LIBRARYPATH to something like "/opt/local/lib:..." (I think)

That is an unusual place for a Mac. Did MacPorts actually put stuff there? Perhaps you should just configure it from source yourself and have it install to /usr/local/lib and it should just work.

Reply

Answer 2

Bill Scott

Level 6

11,459 points

Aug 31, 2007 9:21 AM in response to GabrielZ

As you discovered, setting $DYLD LIBRARYPATH is a bad idea. Applications should have the path hard-coded. So if you use otool on the binary, you should get something like this:

<pre>

zsh-% otool -L /usr/bin/sips
/usr/bin/sips:
/usr/lib/libcrypto.0.9.7.dylib (compatibility version 0.9.7, current version 0.9.7)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 368.26.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Application Services (compatibility version 1.0.0, current version 22.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 63.0.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3)
zsh-%

</pre>

Fink explicitly forbids any package to use this variable, and I would be surprised if it is not the same for MacPorts, although I haven't taken a look at their packaging policies.

So you should use the explicit path to the library in /opt/local at compile-time.

Here is more info:

Creating working dylibs

Reply

Answer 3

Aug 31, 2007 4:23 PM in response to GabrielZ

Hi Gabriel,
Bill and etresoft are correct of course. There actually are advantages to a degree of indirection in specifying libraries, especially in distributing binaries. However, Macs are rather uniform so the advantage is nullified.

Thus, it might not be a great idea to set a LD LIBRARYPATH on a Mac but plenty of open source apps require it. Thus, it never hurts to know how to deal with it but setting it in a shell startup script isn't the way. The setting for one app will almost surely break others. The preferred way to do it is to wrap the invocation of the application in a shell script that sets the DYLD LIBRARYPATH before starting up the app. The shell script runs in a subprocess so setting the environment variable there affects no other processes. Plenty of apps, especially large ones have a startup script.
--
Gary
~~~~
audiophile, n:
Someone who listens to the equipment instead of the music.

Reply

Answer 4

GabrielZ Author

Level 1

65 points

Sep 4, 2007 2:49 AM in response to etresoft

Did MacPorts actually put stuff there

yes, it's the default place where Macports puts its lib's. And Fink puts its lib's into /sw/lib.

Best regards,
Gabriel.

Reply

Answer 5

GabrielZ Author

Level 1

65 points

Sep 4, 2007 3:09 AM in response to Bill Scott

Thanks for your info.
I will try to adjust to this new paradigm of handling dylib paths.

You know, i grew up under Unix, and there i sort of got raised by the mantra "never compile library paths into the application" (i forget the reason).
But then, an app under unix is not a bundle but just an executable (command line tool).

Actually, right now i'm compiling command line tools, too, using makefiles. (I don't even know how to create app bundles 😉 .)

Best regards,
Gabriel.

Reply