From: Howard Spoelstra <hsp.cat7@gmail.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [PULL v7 000/151] Meson-based build system
Date: Fri, 21 Aug 2020 12:58:58 +0200 [thread overview]
Message-ID: <CABLmASECM5tVVw3TMJn+0bCT7O4H_guy5TJd9YQKYYx+QUKBKQ@mail.gmail.com> (raw)
In-Reply-To: <CABLmASFno04tFBRTq=V8AO7dj1d67-SNpugUJMVVa4yzrPq03Q@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5594 bytes --]
On Fri, Aug 21, 2020 at 8:15 AM Howard Spoelstra <hsp.cat7@gmail.com> wrote:
>
>
> On Wed, Aug 19, 2020 at 11:32 PM Paolo Bonzini <pbonzini@redhat.com>
> wrote:
>
>> The following changes since commit
>> d0ed6a69d399ae193959225cdeaa9382746c91cc:
>>
>> Update version for v5.1.0 release (2020-08-11 17:07:03 +0100)
>>
>> are available in the Git repository at:
>>
>> https://gitlab.com/bonzini/qemu.git tags/for-upstream
>>
>> for you to fetch changes up to 2eddb3c65821dce76433d5da6f3e6419349d1b77:
>>
>>
>> Hi,
>
> I attempted to cross compile Qemu for Windows from the meson branch today
> using a Fedora 32 VM and using MSYS2 .
>
> In both cases I compiled using:
> ./configure --cross-prefix=x86_64-w64-mingw32- --target-list=ppc-softmmu
> --enable-gtk --enable-sdl
>
> For the builds to run on Windows I normally copy the pc-bios folder and
> the required dlls (from \msys64\mingw64\bin for the MSYS2 build and from
> /usr/x86_64-w64-mingw32/sys-root/mingw/bin for the Fedora based build).
> This has always worked in the past.
>
> As noticed earlier in discussion with Paolo, with MSYS2 there appears to
> be a difference in how grep works on Linux and Windows. Using grep 3.1 as
> provided by MSYS2, the file config-all-devices.mak file stays empty.
>
> On Fedora the compilation process completed successfully. However, the
> binary crashes. This is the backtrace I could get:
>
> (gdb) attach 11528
> Attaching to process 11528
> [New Thread 11528.0x218]
> [New Thread 11528.0x3380]
> [New Thread 11528.0xf80]
> Reading symbols from C:\qemu-debugging\gdb.exe...(no debugging symbols
> found)...
> done.
> 0x00007ffb9ef0f8b1 in ntdll!DbgBreakPoint ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> (gdb) thread apply all bt full
>
> Thread 3 (Thread 11528.0xf80):
> #0 0x00007ffb9ef0f8b1 in ntdll!DbgBreakPoint ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #1 0x00007ffb9ef3c90e in ntdll!DbgUiRemoteBreakin ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #2 0x00007ffb9dbe6fd4 in KERNEL32!BaseThreadInitThunk ()
> from C:\WINDOWS\System32\kernel32.dll
> No symbol table info available.
> #3 0x00007ffb9eebcec1 in ntdll!RtlUserThreadStart ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #4 0x0000000000000000 in ?? ()
> No symbol table info available.
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> Thread 2 (Thread 11528.0x3380):
> #0 0x00007ffb9ef0c914 in ntdll!ZwWaitForMultipleObjects ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #1 0x00007ffb9c658910 in WaitForMultipleObjectsEx ()
> from C:\WINDOWS\System32\KernelBase.dll
> ---Type <return> to continue, or q <return> to quit---
> No symbol table info available.
> #2 0x00007ffb9c65880e in WaitForMultipleObjects ()
> from C:\WINDOWS\System32\KernelBase.dll
> No symbol table info available.
> #3 0x00000000004291a5 in ?? ()
> No symbol table info available.
> #4 0x00007ffb9dbe6fd4 in KERNEL32!BaseThreadInitThunk ()
> from C:\WINDOWS\System32\kernel32.dll
> No symbol table info available.
> #5 0x00007ffb9eebcec1 in ntdll!RtlUserThreadStart ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #6 0x0000000000000000 in ?? ()
> No symbol table info available.
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
>
> Thread 1 (Thread 11528.0x218):
> #0 0x00007ffb9ef0c914 in ntdll!ZwWaitForMultipleObjects ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #1 0x00007ffb9c658910 in WaitForMultipleObjectsEx ()
> from C:\WINDOWS\System32\KernelBase.dll
> No symbol table info available.
> #2 0x00007ffb9c65880e in WaitForMultipleObjects ()
> ---Type <return> to continue, or q <return> to quit---
> from C:\WINDOWS\System32\KernelBase.dll
> No symbol table info available.
> #3 0x0000000000483e9c in ?? ()
> No symbol table info available.
> #4 0x0000000000551049 in ?? ()
> No symbol table info available.
> #5 0x0000000000550498 in ?? ()
> No symbol table info available.
> #6 0x00000000005504fd in ?? ()
> No symbol table info available.
> #7 0x0000000000551b63 in ?? ()
> No symbol table info available.
> #8 0x00000000005489d7 in ?? ()
> No symbol table info available.
> #9 0x0000000000549421 in ?? ()
> No symbol table info available.
> #10 0x0000000000545e0b in ?? ()
> No symbol table info available.
> #11 0x000000000054a922 in ?? ()
> No symbol table info available.
> #12 0x0000000000545e0b in ?? ()
> No symbol table info available.
> #13 0x000000000054a94d in ?? ()
> No symbol table info available.
> ---Type <return> to continue, or q <return> to quit---
> #14 0x00000000004017e5 in ?? ()
> No symbol table info available.
> #15 0x0000000000401472 in ?? ()
> No symbol table info available.
> #16 0x000000000040117c in ?? ()
> No symbol table info available.
> #17 0x00007ffb9dbe6fd4 in KERNEL32!BaseThreadInitThunk ()
> from C:\WINDOWS\System32\kernel32.dll
> No symbol table info available.
> #18 0x00007ffb9eebcec1 in ntdll!RtlUserThreadStart ()
> from C:\WINDOWS\SYSTEM32\ntdll.dll
> No symbol table info available.
> #19 0x0000000000000000 in ?? ()
> No symbol table info available.
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb)
>
>
I investigated a bit further and saw:
ldd in Fedora tells me the executable is "not a dynamic executable".
Meson seems to default to try a static build and enable pie, whereas a
normal build would require --static to enable that and have pie=no
Best,
Howard
[-- Attachment #2: Type: text/html, Size: 6782 bytes --]
next prev parent reply other threads:[~2020-08-21 11:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-19 21:32 [PULL v7 000/151] Meson-based build system Paolo Bonzini
2020-08-19 21:59 ` Eric Blake
2020-08-19 22:08 ` Paolo Bonzini
2020-08-20 10:33 ` Peter Maydell
2020-08-20 11:52 ` Paolo Bonzini
2020-08-20 14:54 ` Peter Maydell
2020-08-20 16:02 ` Paolo Bonzini
2020-08-20 16:10 ` Peter Maydell
2020-08-21 6:15 ` Howard Spoelstra
2020-08-21 10:58 ` Howard Spoelstra [this message]
2020-08-21 12:33 ` Paolo Bonzini
2020-08-21 16:11 ` Howard Spoelstra
2020-08-21 16:16 ` Paolo Bonzini
2020-08-24 16:18 ` Daniel P. Berrangé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABLmASECM5tVVw3TMJn+0bCT7O4H_guy5TJd9YQKYYx+QUKBKQ@mail.gmail.com \
--to=hsp.cat7@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).