[Bug 42481] Wine does not work well with nonstandard library locations on macOS with SIP

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=42481

--- Comment #2 from jobstz at 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.