https://bugs.winehq.org/show_bug.cgi?id=49199
Bug ID: 49199 Summary: Wine on macOS no longer loads dylibs from /lib(64) Product: Wine Version: 5.6 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: gcenx83@gmail.com
Starting from Wine-5.6 the libwine wrappers have been removed in favor of using dlopen() however this now causes component in question to no longer load embedded dylibs into /lib(64)
Here’s an example;
```907aaf9e72714293909351648827e7c5aebc12a3 is the first bad commit commit 907aaf9e72714293909351648827e7c5aebc12a3 Author: Alexandre Julliard julliard@winehq.org Date: Mon Apr 6 11:46:10 2020 +0200
gdi32: Use standard dlopen() instead of the libwine wrappers.
Signed-off-by: Alexandre Julliard julliard@winehq.org
dlls/gdi32/dibdrv/opengl.c | 12 +++++------- dlls/gdi32/freetype.c | 20 ++++++++++---------- 2 files changed, 15 insertions(+), 17 deletions(-)```
Any commit doing “ Use standard dlopen() instead of the libwine wrappers.” will now experience this.
Previous behavior was the ability to simply embed dylibs into /lib(64) and wine(64) would load them as needed, now rpath is required.
Winehq packages will also experience this issue worse once the current embedded libraries swap to using dlopen()
https://bugs.winehq.org/show_bug.cgi?id=49199
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |3caa3331279be2c99747cde8e36 | |9011378b38e31
https://bugs.winehq.org/show_bug.cgi?id=49199
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|critical |normal
--- Comment #1 from Alexandre Julliard julliard@winehq.org --- I'm not sure what "embedded dylibs" means, or how they were getting loaded from /lib in the first place, but it sounds like a packaging issue.
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #2 from Gcenx gcenx83@gmail.com --- (In reply to Alexandre Julliard from comment #1)
I'm not sure what "embedded dylibs" means, or how they were getting loaded from /lib in the first place, but it sounds like a packaging issue.
Wine-5.5 and below would check its own /lib(64) directly for any required dylibs before checking standard system locations
Each .so would check @loader_path/../ meaning it would check for and use any embedded dylibs, this is desirable to allow wine to be relocatable.
Here is an explanation; ${wine_path}/lib/wine/gdi32.so would precisely check back one directory, that behavior was desirable as the required dylib could be placed into ${wine_path}/lib where it would be loaded reguardless of the current path.
I don’t see how this would be considered a picking issue when this was the previous behavior before these changes.
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #3 from Alexandre Julliard julliard@winehq.org --- I'm still not sure what the mechanism was. Is that because the .dll.so files used to be linked to libwine?
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #4 from Gcenx gcenx83@gmail.com --- (In reply to Alexandre Julliard from comment #3)
I'm still not sure what the mechanism was. Is that because the .dll.so files used to be linked to libwine?
Yes, previously when using libwine along wine_dlopen. Dropping libwine and wine_dlopen wrapper caused this change in behavior.
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- I'm afraid that's not going to work anymore then, libwine is going to be removed. Maybe you could try setting rpath on the .dll.so files.
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #6 from Gcenx gcenx83@gmail.com --- (In reply to Alexandre Julliard from comment #5)
I'm afraid that's not going to work anymore then, libwine is going to be removed. Maybe you could try setting rpath on the .dll.so files.
I understand libwine being removed, I’m asking that winebuild handle adding the additional rpath reference.
While yes I could do this manually after each build it’s less then desirable to run additional tools to basically patch wine functionality.
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- It's questionable to do this by default since it's specific to the way the package is built, but it would be possible to add an easier way for packagers to specify rpath at build time. Patches are welcome.
https://bugs.winehq.org/show_bug.cgi?id=49199
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=49199
Sergey Isakov isakov-sl@bk.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |isakov-sl@bk.ru
--- Comment #8 from Sergey Isakov isakov-sl@bk.ru --- @Gcenx Provide please a possible patch for this issue. I can't make working wine for mac new version.
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #9 from Gcenx gcenx83@gmail.com --- @Sergey What is your issue exactly as this bug is related to shipping the needed dylibs within macOS wine packages, this won’t affect a none portable compile.
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #10 from Sergey Isakov isakov-sl@bk.ru --- (In reply to Gcenx from comment #9)
@Sergey What is your issue exactly as this bug is related to shipping the needed dylibs within macOS wine packages, this won’t affect a none portable compile.
I am using your solutions for wrapper but I compile own engine version (Sherry). Last working was 4.2. New versions even not started under Mojave.
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #11 from Gcenx gcenx83@gmail.com --- (In reply to Sergey Isakov from comment #10)
I am using your solutions for wrapper but I compile own engine version (Sherry). Last working was 4.2. New versions even not started under Mojave.
Do these builds work on your system when ran via terminal without setting DYLD_FALLBACK_LIBRARY_PATH ?
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #12 from Sergey Isakov isakov-sl@bk.ru --- Why DYLD_FALLBACK_LIBRARY_PATH? I never touch it.
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #13 from Gcenx gcenx83@gmail.com --- (In reply to Sergey Isakov from comment #12)
Why DYLD_FALLBACK_LIBRARY_PATH? I never touch it.
As I’d asked in that message, do your build run correctly via terminal?
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #14 from Sergey Isakov isakov-sl@bk.ru --- Created attachment 70408 --> https://bugs.winehq.org/attachment.cgi?id=70408 terminal in Wine
https://bugs.winehq.org/show_bug.cgi?id=49199
--- Comment #15 from Gcenx gcenx83@gmail.com --- (In reply to Sergey Isakov from comment #14)
Created attachment 70408 [details] terminal in Wine
Does everything work correctly when wine is launched normally?, if so then it’s no longer a Winehq issue.
Connect me via discord/email might be useful to also send me the compile so I can see what’s wrong.
https://bugs.winehq.org/show_bug.cgi?id=49199
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|5.6 |unspecified Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC| |dimesio@earthlink.net Product|Wine |Packaging Component|-unknown |wine-packages
--- Comment #16 from Alexandre Julliard julliard@winehq.org --- Assuming resolved.
https://bugs.winehq.org/show_bug.cgi?id=49199
Rosanne DiMesio dimesio@earthlink.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #17 from Rosanne DiMesio dimesio@earthlink.net --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=49199
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |WONTFIX
-
WineHQ Bugzilla