accessing WRT binaries on the web

[Saulius Krasuckas]

Now it seems test are being build daily [1], but none of them shows up on 
the web [2] since 2005.08.16.

Is this intentional state of the system or just some bug had went in it?


[1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php
[2] http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/

[Paul Millar]

Hi Saulius,

No, this isn't intentional.  The cross-building part needs patching so it 
knows about an additional part of the Win32 API.  Nothing new there.

But rather than just patching the (somewhat ancient) version of the w32api, 
I've decided to upgrade to the latest version.  This means going through the 
large number of patches to Win32api figuring out which are now redundant and 
which are still needed, and fixing the patches so they work again.  Once this 
is done, things should be up and running again.

Cheers,

Paul.

On Tuesday 23 Aug 2005 17:13, Saulius Krasuckas wrote:
> Now it seems test are being build daily [1], but none of them shows up on
> the web [2] since 2005.08.16.
>
> Is this intentional state of the system or just some bug had went in it?
>
> [1] http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php
> [2] http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/

[Saulius Krasuckas]

* On Wed, 24 Aug 2005, Paul Millar wrote:
> No, this isn't intentional.  The cross-building part needs patching so 
> it knows about an additional part of the Win32 API.  Nothing new there.

Ok, but I perhaps do not understand, what the exact code is or looks like.  
Is it available on the net?  And are you working alone?
> But rather than just patching the (somewhat ancient) version of the 
> w32api, I've decided to upgrade to the latest version.  This means going 
> through the large number of patches to Win32api figuring out which are 
> now redundant and which are still needed, and fixing the patches so they 
> work again.  Once this is done, things should be up and running again.

Thanks, Paul, for the clarification.

[Paul Millar]

Hi Saulius,

On Thursday 25 Aug 2005 09:22, Saulius Krasuckas wrote:
> * On Wed, 24 Aug 2005, Paul Millar wrote:
> > The cross-building part needs patching so it knows about an additional
> > part of the Win32 API.  Nothing new there.
>
> Ok, but I perhaps do not understand, what the exact code is or looks like.

We're using MinGW for cross-compilation.

This has a few separate parts: binutils, gcc, w32api, run-time, ...  The 
w32api is part of the MinGW distribution, describing the Windows API.  The 
linker uses w32api to build the executable that will link correctly at 
run-time against Windows DLLs.
> Is it available on the net?

Yes, its available.  The vanilla release are available from here:
  http://sourceforge.net/project/showfiles.php?group_id=2435

The w32api releases lag somewhat from what wine actually implements (and so, 
what gets tested).  Because of this, to allow cross-compilation of winetest 
additional API calls need to be patched into w32api.

Precompiled versions of this improved MinGW are maintained by Hans Leidekker 
and are available from:
  http://mirzam.it.vu.nl/mingw/

For somewhat obscure reasons, I've ended up using an independent script to 
generate the cross-compiler but it amounts to the same thing, especially as 
Hans, Stefan Leichter and myself share patches.
> And are you working alone?

No, not at all!  All the patches against w32api have come from Hans or Stefan.
> > [...] Once this is done, things should be up and running again.
>
> Thanks, Paul, for the clarification.

No problem!

OK, so it looks like crypt32_test.exe wasn't building due to missing 
CryptHashCertificate(a)28 definiton (should now be fixed), msi_test.exe due to 
missing MsiViewGetErrorA(a)12 (now fixed) and shell32_test.exe due to missing 
CLSID_FolderShortcut (again, fixed).

But, dsound_test.exe is failing with:

i686-mingw32msvc-gcc capture.o ds3d.o ds3d8.o dsound.o dsound8.o propset.o 
testlist.o   -o dsound_test.exe -ldsound -lole32 -lversion -luser32 
-lkernel32 -ldxguid -luuid -ldxerr8
/usr/local/mingw/lib/gcc-lib/i686-mingw32msvc/3.3.3/../../../../i686-mingw32msvc/lib/libdxguid.a(dxguid.o):/tmp/../../../w32api-3.3/lib/directx/dxguid.c 
(.rdata+0x570): multiple definition of `CLSID_DirectSoundPrivate'
propset.o:/home/paul/Production/wine-cross-source/dlls/dsound/tests/propset.c:66: 
first defined here
/usr/local/mingw/lib/gcc-lib/i686-mingw32msvc/3.3.3/../../../../i686-mingw32msvc/lib/libdxguid.a(dxguid.o):/tmp/../../../w32api-3.3/lib/directx/dxguid.c 
(.rdata+0x580): multiple definition of `DSPROPSETID_DirectSoundDevice'
propset.o:/home/paul/Production/wine-cross-source/dlls/dsound/tests/propset.c:67: 
first defined here

Is this some kind of conflict between the MinGW definitions and wine's own 
version?

Cheers,

Paul

[Filip Navara]

Paul Millar wrote:
[snip]
> i686-mingw32msvc-gcc capture.o ds3d.o ds3d8.o dsound.o dsound8.o propset.o 
> testlist.o   -o dsound_test.exe -ldsound -lole32 -lversion -luser32 
> -lkernel32 -ldxguid -luuid -ldxerr8
> /usr/local/mingw/lib/gcc-lib/i686-mingw32msvc/3.3.3/../../../../i686-mingw32msvc/lib/libdxguid.a(dxguid.o):/tmp/../../../w32api-3.3/lib/directx/dxguid.c 
> (.rdata+0x570): multiple definition of `CLSID_DirectSoundPrivate'
> propset.o:/home/paul/Production/wine-cross-source/dlls/dsound/tests/propset.c:66: 
> first defined here
> /usr/local/mingw/lib/gcc-lib/i686-mingw32msvc/3.3.3/../../../../i686-mingw32msvc/lib/libdxguid.a(dxguid.o):/tmp/../../../w32api-3.3/lib/directx/dxguid.c 
> (.rdata+0x580): multiple definition of `DSPROPSETID_DirectSoundDevice'
> propset.o:/home/paul/Production/wine-cross-source/dlls/dsound/tests/propset.c:67: 
> first defined here
>
> Is this some kind of conflict between the MinGW definitions and wine's own 
> version?

I remember Hans incorrectly adding these defintions to the MinGW library 
... and me not complaining loud enough for the change not to be included 
(or later to be reverted)...

- Filip

[Hans Leidekker]

On Saturday 27 August 2005 13:34, Filip Navara wrote:
> > Is this some kind of conflict between the MinGW definitions and wine's own
> > version?
>
> I remember Hans incorrectly adding these defintions to the MinGW library

I remember that too now :-). I wrongly assumed Wine's header was correct.
Paul, there's a patch in my RPMS that backs out these defines. It's called
w32api_lib_directx_dxguid_c_02.patch.gz

 -Hans

[Paul Millar]

On Saturday 27 Aug 2005 21:28, Hans Leidekker wrote:
> I remember that too now :-). I wrongly assumed Wine's header was correct.
> Paul, there's a patch in my RPMS that backs out these defines. It's called
> w32api_lib_directx_dxguid_c_02.patch.gz

Ta.  I've added that patch too, now.

Next problem is gcc has gone off in the huff and refusing to build anymore (at 
least, as a cross-compiler).  The error message is:
  ../../gcc/crtstuff.c:607: error: mode `SI' applied to inappropriate type
I've not changed gcc, so it must be the result of the new w32api version 
(along with the patches).

Looking at the code, there isn't anything obvious causing the problem.  Since 
I've not changed anything major in gcc, I think I can just ignore the build 
error and use the existing cross-compiler.  This doesn't bode well, though, 
so I'll upgrade to the latest mingw as soon as I've got a few other TODOs out 
of the way ...

So, I'll give this a go and we'll see what happens.

Cheers,

Paul.