https://bugs.winehq.org/show_bug.cgi?id=52618
Bug ID: 52618 Summary: 32-bit EXEs do not launch from build dir on macOS 10.14 in WOW64 Product: Wine Version: 7.3 Hardware: x86-64 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: build-env Assignee: wine-bugs@winehq.org Reporter: bshanks@codeweavers.com
Created attachment 71943 --> https://bugs.winehq.org/attachment.cgi?id=71943 patch to use @rpath
On macOS 10.14, when running Wine built for WOW64 from the build dir, 32-bit EXEs do not launch correctly (including rundll32 on prefix creation to set up syswow64).
64-bit EXEs launch correctly, and a standalone 32-bit build also works correctly. I'm building the 64-bit side with Xcode 10, and the 32-bit side with Xcode 9.
The problem is a crash on the first NtUser* call, since the __wine_syscall_dispatcher was never set in win32u. The root cause is that dlopen() on the unixlibs is failing because ntdll.so cannot be loaded. Here's the dlerror():
177158.077:00ac:00b0:trace:virtual:load_builtin_unixlib loading /Users/pip/wine/build32/dlls/win32u/win32u.so failed dlerror dlopen(/Users/pip/wine/build32/dlls/win32u/win32u.so, 2): Library not loaded: @loader_path/ntdll.so Referenced from: /Users/pip/wine/build32/dlls/win32u/win32u.so Reason: no suitable image found. Did find: /Users/pip/wine/build64/dlls/ntdll/ntdll.so: mach-o, but wrong architecture /Users/pip/wine/build64/dlls/ntdll/ntdll.so: mach-o, but wrong architecture
This doesn't make sense, it almost seems like @loader_path is still set to the 64-bit dlls/ntdll, which it obviously shouldn't be.
Changing the install name to '@rpath/(lib).so' and adding an rpath of '@loader_path/' seems to fix the issue, even though that should be equivalent to the current approach.
Can anyone else reproduce this problem? If so, does the attached patch help?