Alexandre Julliard julliard@winehq.org writes:
Added files: programs/winetest: winetest.h util.c send.c maketest main.c Makefile.in .cvsignore
First of all, thank you very much for adapting and putting this into the tree! Losing some of the automation is not a problem as we seldom have new modules to test.
But we've got an error in the cross-configured tree:
tba:/usr/local/src/wine/pe/dlls/msvcrt/tests/ $ make i586-mingw32msvc-gcc cpp.o file.o heap.o scanf.o testlist.o -o msvcrt_test.exe -L../../../dlls -lmsvcrt -L../../../libs/wine -lwine -L../../../libs/port -lwine_port -lm ../../../dlls/libmsvcrt.a(ds00464.o)(.text+0x0): multiple definition of `atexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00332.o)(.text+0x0): multiple definition of `_onexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:274: first defined here make: *** [msvcrt_test.exe] Error 1
On the other hand,
$ i586-mingw32msvc-gcc cpp.o file.o heap.o scanf.o testlist.o -o msvcrt_test.exe
works all right, and makes winetest.exe build flawlessly.
Best wishes, Feri.
On December 4, 2003 11:47 am, Ferenc Wagner wrote:
First of all, thank you very much for adapting and putting this into the tree! Losing some of the automation is not a problem as we seldom have new modules to test.
Indeed, it looks very nice.
Now Feri, let's try to integrate your CGI scripts into WineHQ. We will need Jer's help, but we need to get the results displayed there (maybe as part of the status page: http://www.winehq.org/site/status)
Once that's done, we need to get someone to build winetest.exe, post it on SourceForge, and announce it to the test team (maybe through the wine-tests list we already have?).
Then we have to get as many people to sign up for the test team. Hopefully we get enough to cover all versions of Windows (in fact, it's good to get many tests on the same version, it will give us confidence, since people have different configurations, etc.).
In the future, we may want to automate the manual process. Namely, we can build a small service/daemon/cronjob for Windows, which checks every so often (say every 3h) at a fix address if a new version of winetest.exe is available. If so, downloads it, runs in non-GUI mode (no MessageBox(), etc.), and submits the result. This way, if someone wants to contribute as a tester, they only need to install this little program and be done with it. The rest happens automatically.
Ferenc Wagner wferi@afavant.elte.hu writes:
But we've got an error in the cross-configured tree:
tba:/usr/local/src/wine/pe/dlls/msvcrt/tests/ $ make i586-mingw32msvc-gcc cpp.o file.o heap.o scanf.o testlist.o -o msvcrt_test.exe -L../../../dlls -lmsvcrt -L../../../libs/wine -lwine -L../../../libs/port -lwine_port -lm ../../../dlls/libmsvcrt.a(ds00464.o)(.text+0x0): multiple definition of `atexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00332.o)(.text+0x0): multiple definition of `_onexit' /usr/lib/gcc-lib/i586-mingw32msvc/2.95.3-7/../../../../i586-mingw32msvc/lib/crt2.o:/home/ron/devel/debian/mingw32-runtime/mingw32-runtime-3.2/build_dir/src/mingw-runtime-3.2/crt1.c:274: first defined here make: *** [msvcrt_test.exe] Error 1
That's a mingw bug, their handling of atexit is not compatible with the way Windows does it. You can work around it by not using the Wine msvcrt import lib.
Alexandre Julliard julliard@winehq.org writes:
That's a mingw bug, their handling of atexit is not compatible with the way Windows does it.
I hope they know about it and will fix...
As a second thought, using CreateDirectory seems shaky for me. Doesn't it depend on /tmp (or whatever tempnam() prefers) being accessible as a configured DOS drive?
Feri.
On Fri, 5 Dec 2003, Ferenc Wagner wrote: [...]
As a second thought, using CreateDirectory seems shaky for me. Doesn't it depend on /tmp (or whatever tempnam() prefers) being accessible as a configured DOS drive?
Or maybe it's the use of tempnam() that is shaky on Windows. Why not use GetTempPath + GetTempFileName?
-
Alexandre Julliard -
Dimitrie O. Paun -
Ferenc Wagner -
Francois Gouget