Am 26.02.24 um 05:35 schrieb Bin Meng: > On Mon, Feb 26, 2024 at 1:37 AM Stefan Weil wrote: >> Am 10.09.22 um 02:37 schrieb Bin Meng: >>> On Sat, Sep 10, 2022 at 12:49 AM Mark Cave-Ayland >>> wrote: >>>> On 08/09/2022 14:28, Bin Meng wrote: >>>> >>>>> From: Bin Meng >>>>> >>>>> 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 >>>>> --- >>>>> >>>>> 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). Stefan