On 15/11/15 05:19, Daniel Johnson wrote: [] > You can try, but I doubt it’ll make a difference. As far as Apple is > concerned, this is a feature, not a bug. Disabling DYLD_LIBRARY_PATH is part > of System Integrity Protection as being able to interpose a different library > is a security risk. If you disable SIP, DYLD_LIBRARY_PATH works again.
If I understand the discussion correctly, the DYLD_* env variables are only disabled for certain executables that are considered inviolable. Shells belong to this class, but the fact that this then concerns also subshells and shell scripts is probably unintended and can be considered as a bug. > DYLD_FALLBACK_LIBRARY_PATH still works so maybe it can be used instead. I > haven’t looked at the code in question. No, DYLD_FALLBACK_LIBRARY_PATH does not help in the case of qt3 and some other packages where DYLD_LIBRARY_PATH is used during the build process to run newly compiled binaries that are linked against newly compiled libraries. This allows the dylibs to have their install_name set to their final destination while still living in the build directory. If DYLD_LIBRARY_PATH is not available, more complicated procedures involving changing install_names at the last moment before installation would have to be followed. Cmake, for example, has such procedures, but last time I looked they didn't work reliably in all cases. Fink has several dozen packages that use DYLD_LIBRAY_PATH and might be affected by this "feature", among them basics like ncurses, bzip2, python or texlive. I am maintaining a couple of those, too, and this might just give me the final push to abandon them. -- Martin ------------------------------------------------------------------------------ _______________________________________________ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
