https://bugs.winehq.org/show_bug.cgi?id=42481
--- Comment #2 from jobstz@posteo.de --- The setting of the DYLD_* variables was more meant to be seen as a workaround, that used to work before SIP. e.g Before executing
winecfg
one could set DYLD_FALLBACK_LIBRARY_PATH to something meaningful, then winecfg would execute
wine
with DYLD_FALLBACK_LIBRARY_PATH still being the same. Nowadays it gets cleared by SIP.
But since I have libs in a non-standard location I cannot run `winecfg`, because then `wine` has no idea how to find them.
I took a look into the prebuilt binaries you mentioned and found they had edited the @rpath of `wine` to make it find the X11 library. Copying that approach fixes my issue, but the workaround is rather cumbersome.
To summarize: - On macOS every lib comes with an `install_name` that gets copied into any linked executable, so that the dynamic loader can locate it upon launch - Wine however does not really link against the common libs (freetype, libpng, ...) but rather loads them at runtime with dlopen() and friends --> The install names never get copied into `wine` and hence the dynamic loader cannot find them, if they are in a non-standard location
This is unfortunate as wine builds properly on my computer, but cannot be run without fixing up the @rpath. Directly linking against the libs and not using dlopen() would resolve this, but I suppose wine has its reasons not to...
But then this is probably more a packaging issue, than a core wine issue.