search

libvips / nip2

A spreadsheet-like GUI for libvips.
https://libvips.github.io/libvips/
GNU General Public License v2.0
362 stars 13 forks source link

run-nip2.sh should not use DYLD_LIBRARY_PATH on Darwin #50

Closed nieder closed 8 years ago

nieder commented 9 years ago

On Darwin, using DYLD_LIBRARY_PATH causes a runtime failure when using the 'helper' script run-nip2.sh

dyld: Library not loaded: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
  Referenced from: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
  Reason: Incompatible library version: vecLib requires version 1.0.0 or later, but libLAPACK.dylib provides version 0.0.0
Trace/BPT trap: 5

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html

If you're going to play with dyld search paths, you should at worst use DYLD_LIBRARY_FALLBACK_PATH (at best skip setting anything at all to mess with dyld). On OS X, shared libraries have a hardcoded install_name attached to them, and when a program (or another library) links to one, it saves the install_name location at linktime and uses that to find the library. Using DYLD_LIBRARY_PATH shortcircuits that search and is really recommended only to find libraries that have not yet been installed to their final runtime location (as when running tests on a newly built library before installation).

jcupitt commented 9 years ago

Hi @nieder, thanks for pointing this out. The run-nip2.sh script dates from quite a few years ago when not all platforms had rpath or equivalent, I'll remove it.

The startup script for nip2.app messes with DYLD_LIBRARY_PATH, should that set FALLBACK_PATH instead?

https://github.com/jcupitt/build-osx/blob/master/7.40/nip2-launcher.sh

nieder commented 9 years ago

I'm not sure. The big problem with setting it in run-nip2.sh is that it ended up pointing to a system directory, and dyld was going to be sloppy and use the first library it could find there that satisfied the name (in my case liblapack.dylib from atlas instead of the system libLAPACK.dylib from vecLib.framework). As upstream, you have no control as to what's going to be present in that folder.

On the other hand, the .app is a closed ecosystem, and DYLD_LIBRARY_PATH should be OK there because you in theory are 100% in control of the libraries inside the .app bundle. I'm not sure if it's the current best practices, but it might be OK.

jcupitt commented 9 years ago

OK, run-nip2.sh removed.

jcupitt commented 9 years ago

... and thank you for pointing out these dumb things, nip2 has been a bit unloved for the last few years, it's good to fix it up a bit.