[Bug 52618] New: 32-bit EXEs do not launch from build dir on macOS 10.14 in WOW64

WineHQ Bugzilla wine-bugs at winehq.org
Wed Mar 2 16:25:18 CST 2022


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 at winehq.org
          Reporter: bshanks at 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.



More information about the wine-bugs mailing list