Am 26.02.24 um 05:35 schrieb Bin Meng:
On Mon, Feb 26, 2024 at 1:37 AM Stefan Weil<sw@weilnetz.de> wrote:
Am 10.09.22 um 02:37 schrieb Bin Meng:
On Sat, Sep 10, 2022 at 12:49 AM Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
On 08/09/2022 14:28, Bin Meng wrote:
From: Bin Meng<bin.meng@windriver.com>
At present packaging the required DLLs of QEMU executables is a
manual process, and error prone.
Actually build/config-host.mak contains a GLIB_BINDIR variable
which is the directory where glib and other DLLs reside. This
works for both Windows native build and cross-build on Linux.
We can use it as the search directory for DLLs and automate
the whole DLL packaging process.
Signed-off-by: Bin Meng<bin.meng@windriver.com>
---
meson.build | 1 +
scripts/nsis.py | 46 ++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 43 insertions(+), 4 deletions(-)
[...]>>> diff --git a/scripts/nsis.py b/scripts/nsis.py
index baa6ef9594..03ed7608a2 100644
--- a/scripts/nsis.py
+++ b/scripts/nsis.py
@@ -18,12 +18,36 @@ def signcode(path):
return
subprocess.run([cmd, path])
+def find_deps(exe_or_dll, search_path, analyzed_deps):
+ deps = [exe_or_dll]
+ output = subprocess.check_output(["objdump", "-p", exe_or_dll], text=True)
This fails on non x86 hosts where objdump does not know how to handle a
Windows x86_64 exe file.
Does this command work in the MSYS2 environment on Windows Arm?
I don't know and cannot test that, because I don't run Windows on ARM.
+ output = output.split("\n")
+ for line in output:
+ if not line.startswith("\tDLL Name: "):
+ continue
+
+ dep = line.split("DLL Name: ")[1].strip()
+ if dep in analyzed_deps:
+ continue
+
+ dll = os.path.join(search_path, dep)
+ if not os.path.exists(dll):
+ # assume it's a Windows provided dll, skip it
+ continue
+
+ analyzed_deps.add(dep)
+ # locate the dll dependencies recursively
+ rdeps = find_deps(dll, search_path, analyzed_deps)
+ deps.extend(rdeps)
+
+ return deps
[...]
FWIW I wrote a similar script a while back to help package a custom Windows
build for
a client, however I used ldd instead of objdump since it provided the full
paths for
DLLs installed in the msys2/mingw-w64 environment via pacman which were outside
the
QEMU build tree.
Yep, ldd also works, but only on Windows native build. objdump can
work on both Windows native and Linux cross builds.
objdump fails on Linux cross builds on any non x86 host, because objdump
typically only supports the native host architecture.
Therefore I get an error on an ARM64 host (podman on Mac M1):
objdump: /tmp/tmpvae5u0qm/qemu/qemu-system-aarch64.exe: file
format not recognized
I could use x86_64-w64-mingw32-objdump to fix the cross builds, but then
native builds might fail because they don't have x86_64-w64-mingw32-objdump.
Is there a simple way how we can get the information here whether
objdump requires a cross build prefix?
For QEMU Windows, I believe the only supported architecture is x86_64,
correct? Do we want to support (cross) building QEMU for Windows Arm?
Yes, I think we only support QEMU on Windows x86_64. I also don't know anyone who has
tried building for Windows ARM. And up to now I also was never asked for that, so
obviously there is still no need for it.
Based on your observation, objdump on Linux cross builds on any x86
host works, but not on non x86 host.
Maybe it's a hint to ask for binutils guys to include the PE format
support for objdump Arm by default.
I am afraid that we'll have to find a solution on the QEMU side, not wait until all
binutils support the PE format for x86_64 (which would make the binaries or the
library much larger).