Building Wine conformance tests on Windows
Hello there, It appears that it is not possible to build the Wine conformance tests on Windows as described here: http://www.winehq.org/site/docs/winedev-guide/testing-windows In particular, when I try to build against the latest Windows SDK I get all sorts of errors. Take for example, kernel32/tests/loader.c. It refers to IMAGE_FILE_MACHINE_ARM64. This symbol does not exist in winnt.h from Microsoft but does exist in the wine version. How do people build the conformance tests? Cross compile on Linux? Thanks, albert
Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote:
Take for example, kernel32/tests/loader.c. It refers to IMAGE_FILE_MACHINE_ARM64. This symbol does not exist in winnt.h from Microsoft but does exist in the wine version.
In this particular case the test needs to be fixed. Another solution is to build with Wine headers. -- Dmitry.
Thanks Dimitry, I'm new to wine so please excuse my naïveté and ignorance. RE: the test needs to be fixed There are lots of other errors. It looks like nobody has tried to build against the windows sdk headers for some time. I could try to fix it but if this isn't the way people work then it will get broken again and again. I'd rather stay on the beaten path than bushwhack on some old overgrown trail. RE: Another solution is to build with the Wine headers I've also tried this and it gets me further but not all the way. I'm just trying to build the kernel32 tests for now and I get a linker error: volume.obj : error LNK2019: unresolved external symbol _strcasecmp referenced in function _test_GetVolumePathNameA This is expected since _strcasecmp is called stricmp on Windows. This really makes me wonder if building these tests on Windows is at all viable. It seems that people use some other method to build this stuff. I've checked winetest64.exe from http://test.winehq.org/data/ and it definitely wasn't built with the Microsoft toolset. I think I'll move on and try to cross compile on Linux, I suspect that's the beaten path. albert -----Original Message----- From: Dmitry Timoshkov [mailto:dmitry.timoshkov(a)gmail.com] On Behalf Of Dmitry Timoshkov Sent: Thursday, May 1, 2014 22:40 To: Albert Szilvasy Cc: wine-devel(a)winehq.org Subject: Re: Building Wine conformance tests on Windows Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote:
Take for example, kernel32/tests/loader.c. It refers to IMAGE_FILE_MACHINE_ARM64. This symbol does not exist in winnt.h from Microsoft but does exist in the wine version.
In this particular case the test needs to be fixed. Another solution is to build with Wine headers. -- Dmitry.
On 2 May 2014 19:34, Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote:
This really makes me wonder if building these tests on Windows is at all viable. It seems that people use some other method to build this stuff. I've checked winetest64.exe from http://test.winehq.org/data/ and it definitely wasn't built with the Microsoft toolset. I think I'll move on and try to cross compile on Linux, I suspect that's the beaten path.
If you only care about building the tests to run them on Windows (as opposed to building the tests on Windows specifically), I think "make crosstest" is the easiest way. You may have to install mingw-w64 for that to work.
On 05/02/2014 07:44 PM, Henri Verbeet wrote:
On 2 May 2014 19:34, Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote:
This really makes me wonder if building these tests on Windows is at all viable. It seems that people use some other method to build this stuff. I've checked winetest64.exe from http://test.winehq.org/data/ and it definitely wasn't built with the Microsoft toolset. I think I'll move on and try to cross compile on Linux, I suspect that's the beaten path.
If you only care about building the tests to run them on Windows (as opposed to building the tests on Windows specifically), I think "make crosstest" is the easiest way. You may have to install mingw-w64 for that to work. In that case there is even an easier solution: Just throw the patch at the WineTestBot https://testbot.winehq.org/ You can then download the binary from there in addition to have the testbot run it on its Windows VMs.
bye michael
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-05-02 19:34, schrieb Albert Szilvasy:
There are lots of other errors. It looks like nobody has tried to build against the windows sdk headers for some time. I could try to fix it but if this isn't the way people work then it will get broken again and again. I'd rather stay on the beaten path than bushwhack on some old overgrown trail. I am building the d3d tests and libraries with Visual Studio 2013. I sent a number of patches to fix them, but I am sure many more remain outside the d3d code. I'm also using Wine's headers because I am building parts of the implementation as well.
I am using Microsoft's import libraries where possible. This currently fails for d3d8 (because it doesn't exist any longer) and d3dcompiler (because D3DDisassemble is a private export). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTY/HcAAoJEN0/YqbEcdMwUIgP/39a8gnOG6Q4ZOsjkdUNf7Eg cLlSB7FBaH+ePPC/7dxExYAvov7rPFMF1n7L9Wr4zSJTiffEEWZE1NPYsscrVZvS SJxB/tbHZNIDwVhf7+cs2Un8ExtUG9YMj0kL8B2KCyikiY5fa2vi+mgOuO1uIzPP GnKmuySPFtMyUGYtohvPlh1y2qOgWbAFgLuXTx4wtpJx/DMNmzs8escbIeEvhXmT BO5QuF6BFDawMq1k5pSW7UFezHp7gsoNj8OeuI2iJNEp/QilZtl0JJoRNo7ePrKc K86f1EW5KbsbHElnNFL/QiselAyGdTpyWIjXvVuX7sDM+sQQCKg2LZjWcx72svk/ LULZ9GZo/816ZHHKhoAnMCZyEf1D8qwMe1lnwkv4aZKmt0//+imSNQrZfctkpF/S sNnRwDPdGKKuzsCyZrK16FetYSwjHKC6gHKEDEnIL/lL41nsoshrkjCPZub+cdT/ g5waUORYUGmgQ7pUuv/UD8umFTwLqlR8j7SMa/aaPtsKN/o4TlO2OrN23USha3ds 0MXYAkZxgQdoQWBENbNdub76FYH/45furiCtXkbpfvNeUENuXbHCVA5o9M7TGU7I 2gpLvukO3AoXEkh1XM8VU5SZJCGl9G2o7HwbxOSyY0k/GAJNNY1uS+l3MScVOk03 wmcivp9mstSOrINl7g5H =J/JN -----END PGP SIGNATURE-----
Albert Szilvasy wrote:
RE: the test needs to be fixed
There are lots of other errors. It looks like nobody has tried to build against the windows sdk headers for some time. I could try to fix it but if this isn't the way people work then it will get broken again and again. I'd rather stay on the beaten path than bushwhack on some old overgrown trail.
At least the avifil32 tests were known not to build on Windows and it is not trivial to fix the problem. If you just need the tests, cross-compilation is easy. If you really need to build on Windows, I suspect that getting at least the most important tests to build would be possible without much effort, but I could be completely wrong. Best regards, Julius
Albert Szilvasy <albert.szilvasy(a)autodesk.com> wrote:
RE: the test needs to be fixed
There are lots of other errors. It looks like nobody has tried to build against the windows sdk headers for some time. I could try to fix it but if this isn't the way people work then it will get broken again and again. I'd rather stay on the beaten path than bushwhack on some old overgrown trail.
I routinely build Wine tests with PSDK headers and tools when I start working on some area in Wine which needs tests. Probably a few other people build Wine tests under Windows as well, but probably most of developers simply crosscompile since it's way easier.
RE: Another solution is to build with the Wine headers
I've also tried this and it gets me further but not all the way. I'm just trying to build the kernel32 tests for now and I get a linker error: volume.obj : error LNK2019: unresolved external symbol _strcasecmp referenced in function _test_GetVolumePathNameA
This is expected since _strcasecmp is called stricmp on Windows.
A test failing to compile with PSDK is a bug, and eventually should be fixed. I'd suggest to limit the effort by the tests you really need at this point and make only them build with PSDK as an exersize, once you do it fixing other tests will be much easier. -- Dmitry.
participants (6)
-
Albert Szilvasy -
Dmitry Timoshkov -
Henri Verbeet -
Julius Schwartzenberg -
Michael Stefaniuc -
Stefan Dösinger