Re: [Qemu-devel] 64-bit build of qemu-system-arm with mingw-w64 not functional

[Stefan Weil <sw@weilnetz.de>]

Am 09.04.2015 um 21:44 schrieb Liviu Ionescu:
> hmmm... things get complicated, even messier. :-(

Windows support _is_ complicated, yes.

There is MinGW32, MinGW-w64, Cygwin, Cygwin64 (list incomplete).

And some versions of MinGW-w64 are incompatible because they
changed their name mangling, so there are pre-compiled libraries
with and without leading underscores in symbol names.

Different models for exception handling exist and require different
toolchains.

The dependencies required for QEMU must be collected from different
sources, and maybe they depend on different variants of zlib or libz.
Or you have to get the sources and build one after the other.

And all this runs on a closed source system which sometimes
remembers a black hole.

> first I was confident, I wrote my multi-platform build script that worked for all platforms, except win64; then I reverted, trying to build the official version, and since you remember having successful win64 builds, I took it as reference. unfortunately the build was not successful, due to the missing libraries; then I considered Stefan's binaries to be the 'official' QEMU releases for windows, just to find out that they are actually based on a fork, that I'm invited to check for differences...

I thought the documentation on my website were clear, but if it is not,
suggestions for improvement are welcome.

I try to keep my fork close to the official version. As this is voluntary
work done in my free time, there can be delays in the synchronization.
My fork also contains additional code which would need much work
to integrate it in the official QEMU (MIPS AR7 with WLAN router emulation,
Raspberry Pi emulation and other parts which are not always working).
I don't think those differences are important for your problem, but if
you would run a short test, we could be sure.

By the way: I still don't have your test setting, so I have no chance to
reproduce it. Is the test.elf which you use publicly available?

> it seems to never end...
>
> the fact is: the public version from the project git, cross built for 64-bit on a fresh Debian 8, with the (old) packages from Stefan, and with the configuration you suggested, builds successfully, but... fails to run. the 32-bit version, built in the exactly the same conditions, is ok.
>
> I don't exclude a systematic error that I made in my builds, but, from what I see, my tests are far more rigorous than what I found up to now, and I'd rather suspect the problem to be somewhere else.
>
> it might very well be a problem with the treading support, slightly differently implemented on win64.
>
> ---
>
>> SDL comes from a locally cross built libSDL.
> ok, I expected this. :-(

:-) (my binaries for SDL are online now, http://qemu.weilnetz.de/debian/)

>
>> Maybe it is better for your tests to build
> without SDL support,
>
> in GNU ARM Eclipse QEMU I do not use SDL, but I just wanted to reproduce the exact conditions you use for your builds.
>
>>> - "make installer" did not pack any DLL inside the setup
>> It has a built-in magic: all DLL files from $(SRC_PATH)/dll/w64 are
>> taken for the 64 bit build (w32 for 32 bit build).
> great, I like magic, but what I do not understand is why this magic is not in the public git, for us all to use it?

It is. Not many people want to build QEMU installers for Windows,
and those who do usually find a way how to do it.

As I said above: suggestions for improvement are welcome.


>
>> Get a list of all needed DLL files either by try and error or by using
>> tools and copy them (or make symbolic links) to that directory.
> I did this for my builds, I just wanted to clarify things for the official build.
>
> is it that complicated to share **all** build scripts and related details, preferably to contribute them back to the project?

As you see, I am willing to share any information which is needed.

>> There is an nsis macro W64 which switches the program directory (see qemu.nsi).
> I have a far more elaborate nsis configuration for my builds; the problem is that the official 'make install' does not generate a functional setup (the dlls are not there, and the setup does not write the program in the proper place), and since your setup seems functional, it would be great to update the project.

'make install' installs (in the wrong place). You are invited to fix it. 
I never use it.

'make installer' creates an installer.

>
>> Maybe you can try my QEMU fork from http://repo.or.cz/w/qemu/ar7.git
>> and see whether it works for you.
> are your actual build scripts in the repo? or in some public place?

I already told you my configure + make commands - nothing magic with them
and they create working binaries here.

> all my scripts are in the GNU ARM Eclipse QEMU repo, and not only the build script is self contained, but all information necessary to run it is public.
>
> even more, now I'm migrating the build processes to using Docker, which is an even more reproducible and scriptable solution, exactly to avoid this kind of embarrassing situation that we are now in, with the mysterious win64 build.

That's great.

Cheers
Stefan