[Bug 42481] New: Wine does not work well with nonstandard library locations on macOS with SIP
https://bugs.winehq.org/show_bug.cgi?id=42481
Bug ID: 42481 Summary: Wine does not work well with nonstandard library locations on macOS with SIP Product: Wine Version: 2.2 Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jobstz@posteo.de
With the introduction of SIP (System integrity protection) there is no longer any propagation of DYLD_* environment variables to child processes. This effectively means that wine has (big) troubles finding libraries in non-standard locations. One solution would be to use absolute linking paths to the libs. That could probably be enabled by a configure option. I am unsure of the consequences though...
See also: https://github.com/Homebrew/homebrew-core/issues/8846
https://bugs.winehq.org/show_bug.cgi?id=42481
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #1 from Sebastian Lackner sebastian@fds-team.de --- I don't think Wine makes use DYLD_* environment variables for the purpose of finding dependencies.
Could you please test if this problem be reproduced with WineHQ OSX packages? See https://dl.winehq.org/wine-builds/macosx/download.html
https://bugs.winehq.org/show_bug.cgi?id=42481
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
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.
https://bugs.winehq.org/show_bug.cgi?id=42481
--- Comment #3 from jobstz@posteo.de --- One more note: `wine` seems to always come with one RPATH set to "@loader_path/../lib", which fixes the issue assuming that the libs will be there. But in e.g a homebrew installation they are not.
https://bugs.winehq.org/show_bug.cgi?id=42481
--- Comment #4 from Ken Thomases ken@codeweavers.com --- (In reply to jobstz from comment #0)
With the introduction of SIP (System integrity protection) there is no longer any propagation of DYLD_* environment variables to child processes.
This is not quite accurate. DYLD_* variables are only stripped when exec-ing protected binaries. There is no general prohibition against them propagating to child processes. Unfortunately, the system-provided script interpreters, such as /bin/sh, are protected binaries. So, DYLD_* variables are stripped when a shell script is started.
But, for example, if one had a wine script to wrap the launching of the wine executable and that script itself were to set DYLD_* variables before running the wineloader executable, those variables would be inherited by and affect the operation of the wineloader process as desired.
I don't know exactly what Homebrew does for its Wine install or how it currently tries to use DYLD_* variables. Mechanisms are available to avoid this problem, at least in theory.
https://bugs.winehq.org/show_bug.cgi?id=42481
--- Comment #5 from jobstz@posteo.de --- The DYLD_* stuff was always my workaround to this issue, it is not implemented in homebrew and it should not be imao. I grant you the point that homebrew could provide measures to fix this, but my serious note being: If I have my libs in a non-standard location and run configure/make, wine will still build just fine, because pkg-config knows about the lib/header locations. But afterwards I will be unable to run wine without setting DYLD_* or RPATH or some other black magic. This seems undesirable to me.
-
wine-bugs＠winehq.org