#1104097 dxvk: builds x86 PE DLLs for Wine on arm64 and armhf, is this intended?

Package:
src:dxvk
Source:
src:dxvk
Submitter:
Simon McVittie
Date:
2025-08-17 06:09:01 UTC
Severity:
normal
Tags:
#1104097#5
Date:
2025-04-25 15:33:43 UTC
From:
To:
While looking at DXVK Native I noticed that the setup of the older
Wine-based DXVK builds on ARM architectures seems odd.

If I understand correctly, Wine exists on armhf and arm64, on which it
implements the interface of the rarely-seen 32- and 64-bit ARM versions
of Windows, therefore it will be running ARM PE executables and DLLs.
Debian's Wine packaging seems to use `clang -target aarch64-windows` as
a cross-compiler that will output 64-bit ARM PE DLLs, and similarly
`clang -target armv7-windows` for 32-bit.

But when we build src:dxvk on armhf and arm64, it seems to be using
i686-w64-mingw32-g++ and x86_64-w64-mingw32-g++ respectively, which are
cross-compilers that output 32- and 64-bit **x86** PE DLLs. Is that
how it's meant to work?

It would seem to me that Wine will be unable to load an x86 PE DLL into
an ARM process, therefore if there are x86 DLLs in dxvk-wine32:armhf and
dxvk-wine64:arm64, they won't be practically useful? But perhaps I'm
misunderstanding something?

If I'm getting this right, then instead of `build-win32.txt` and
`build-win64.txt`, on armhf and arm64 dxvk should be using a Meson
cross-file that selects clang-based tools, something like this:

[binaries]
c = ['clang', '-target', 'aarch64-windows', '-fuse-ld=...', ...]
cpp = ['clang++', '-target', 'aarch64-windows', '-fuse-ld=...', ...]
ar = (??? I don't know what goes here)
strip = ...
windres = ...

[properties]
needs_exe_wrapper = true

[host_machine]
system = 'windows'
cpu_family = 'aarch64'
cpu = 'aarch64'
endian = 'little'

... and something analogous for armhf?

(But, again, it's entirely possible that I'm misunderstanding.)

    smcv

#1104097#10
Date:
2025-08-17 06:01:18 UTC
From:
To:
I really don't like cross compilation. Sometimes the host is the build,
sometimes it's the target, or other funky combination… it's like time
travel and, quoting Kathryn Janeway, « it all gives me a headache ».

That said, your analysis sounds right. The main problem here is that
clearly you do not have any of these architectures at hand to test, and
so do I, and noone reported any problem. So whatever change we end up
doing we're still not sure it's gonna work well.

I'm open to making such changes but tagging this bug for help for now
and when we have a way to check the results then I'll spend more time on
it.

Regards.
\_o<