[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(a)winehq.org Reporter: jobstz(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42481 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #1 from Sebastian Lackner <sebastian(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42481 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42481 --- Comment #2 from jobstz(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42481 --- Comment #3 from jobstz(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42481 --- Comment #4 from Ken Thomases <ken(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=42481 --- Comment #5 from jobstz(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org