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(a)winehq.org Reporter: bshanks(a)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? -- 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.