Setting DYLD_LIBRARY_PATH tells macOS that you know better than it where it should load libraries from. The consequence on recent macOS versions is that the program crashes on launch when the OS tries to load stardict's bundled zlib instead of the slightly different one that it needs that's in the macOS ImageIO framework.
If you need to set DYLD_LIBRARY_PATH at runtime for your program to work it is an indication that your program is not linked correctly. However the stardict 3.0.5 beta 1 binary for macOS is linked correctly (the execuable refers to the bundled libraries via correct relative paths based on @executable_path) so DYLD_LIBRARY_PATH is not needed here.
The same change was made in gtk-mac-bundler, from which this script was probably originally taken:
Setting
DYLD_LIBRARY_PATH
tells macOS that you know better than it where it should load libraries from. The consequence on recent macOS versions is that the program crashes on launch when the OS tries to load stardict's bundled zlib instead of the slightly different one that it needs that's in the macOS ImageIO framework.If you need to set
DYLD_LIBRARY_PATH
at runtime for your program to work it is an indication that your program is not linked correctly. However the stardict 3.0.5 beta 1 binary for macOS is linked correctly (the execuable refers to the bundled libraries via correct relative paths based on@executable_path
) soDYLD_LIBRARY_PATH
is not needed here.The same change was made in gtk-mac-bundler, from which this script was probably originally taken:
https://gitlab.gnome.org/GNOME/gtk-mac-bundler/-/commit/9938068b73f2e6d304137b94ece713890b96eaa2
Closes #94