Couldn't winetest fill in the proper test results fields necessary for acceptance when compiled to an exe.so and run in wine?
Robert Reif reif@earthlink.net writes:
Couldn't winetest fill in the proper test results fields necessary for acceptance when compiled to an exe.so and run in wine?
Did you make dist in programs/winetest? winetest-dist.exe is the program meant for submission, but winetest-dist.exe.so should be able to submit as well. However, its use is discouraged, as it would run under Wine only. Unfortunately, cross-building seems broken ATM. Kevin, Paul, can you comment on this? I remember Paul sending a report to wine-devel about a week ago, do we still suffer from the same problem?
On Monday 11 October 2004 10:57, Ferenc Wagner wrote:
Unfortunately, cross-building seems broken ATM. Kevin, Paul, can you comment on this? I remember Paul sending a report to wine-devel about a week ago, do we still suffer from the same problem?
Yup, the problem is still there; at least, for me.
Strangely enough, it worked twice last week: Tuesday 12th and Wednesday 13th builds. But since then its been failing with the same problem.
Here's what the script has to say:
Ran command "make depend", but it failed with following output: make[1]: Entering directory `/home/paulm/Production/wine-cross-pe/libs' make[2]: Entering directory `/home/paulm/Production/wine-cross-pe/libs/port' i686-mingw32msvc-gcc -c -I/home/paulm/Production/wine-cross-source/libs/port -I. -I/home/paulm/Production/wine-cross-source/include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o fstatvfs.o /home/paulm/Production/wine-cross-source/libs/port/fstatvfs.c In file included from /home/paulm/Production/wine-cross-source/libs/port/fstatvfs.c:22: /home/paulm/Production/wine-cross-source/include/wine/port.h:286: warning: `struct timeval' declared inside parameter list /home/paulm/Production/wine-cross-source/include/wine/port.h:286: warning: its scope is only this definition or declaration, which is probably not what you want i686-mingw32msvc-gcc -c -I/home/paulm/Production/wine-cross-source/libs/port -I. -I/home/paulm/Production/wine-cross-source/include -I../../include -D__WINESRC__ -D_REENTRANT -Wall -pipe -fno-strength-reduce -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o futimes.o /home/paulm/Production/wine-cross-source/libs/port/futimes.c distcc[20306] ERROR: compile on melpomene failed In file included from /home/paulm/Production/wine-cross-source/libs/port/futimes.c:22: /home/paulm/Production/wine-cross-source/include/wine/port.h:286: warning: `struct timeval' declared inside parameter list /home/paulm/Production/wine-cross-source/include/wine/port.h:286: warning: its scope is only this definition or declaration, which is probably not what you want /home/paulm/Production/wine-cross-source/libs/port/futimes.c:33: error: conflicting types for `futimes' /home/paulm/Production/wine-cross-source/include/wine/port.h:286: error: previous declaration of `futimes' make[2]: *** [futimes.o] Error 1 make[2]: Leaving directory `/home/paulm/Production/wine-cross-pe/libs/port' make[1]: *** [port] Error 2 make[1]: Leaving directory `/home/paulm/Production/wine-cross-pe/libs' make: *** [libs] Error 2 ERROR: make depend failed
"Paul Millar" paulm@astro.gla.ac.uk wrote:
fstatvfs.o /home/paulm/Production/wine-cross-source/libs/port/fstatvfs.c In file included from /home/paulm/Production/wine-cross-source/libs/port/fstatvfs.c:22: /home/paulm/Production/wine-cross-source/include/wine/port.h:286: warning: `struct timeval' declared inside parameter list
This should be fixed by the patch "Include sys/time.h in wine/port.h in order to get struct timeval definition for futimes on Cygwin" I sent yesterday to wine-patches.
Ferenc Wagner wrote:
Robert Reif reif@earthlink.net writes:
Couldn't winetest fill in the proper test results fields necessary for acceptance when compiled to an exe.so and run in wine?
Did you make dist in programs/winetest? winetest-dist.exe is the program meant for submission, but winetest-dist.exe.so should be able to submit as well.
make dist make: *** No rule to make target `build.id', needed by `dist.res'. Stop.
For the built in wine, run with wine case, couldn't there be reasonable default values rather than reading them from a file?
Robert Reif reif@earthlink.net writes:
Ferenc Wagner wrote:
Robert Reif reif@earthlink.net writes:
Couldn't winetest fill in the proper test results fields necessary for acceptance when compiled to an exe.so and run in wine?
Did you make dist in programs/winetest? winetest-dist.exe is the program meant for submission, but winetest-dist.exe.so should be able to submit as well.
make dist make: *** No rule to make target `build.id', needed by `dist.res'. Stop.
For the built in wine, run with wine case, couldn't there be reasonable default values rather than reading them from a file?
That's exactly what we wanted to avoid. Submitted results should * not come from Wine but genuine Windows systems, and * be identifiable. So we decided to require some (small, one time) effort of people providing test suites. For what you are doing, make test seems worth consideration. If I guessed correctly. :)
Ferenc Wagner wrote:
Robert Reif reif@earthlink.net writes:
Ferenc Wagner wrote:
Robert Reif reif@earthlink.net writes:
Couldn't winetest fill in the proper test results fields necessary for acceptance when compiled to an exe.so and run in wine?
Did you make dist in programs/winetest? winetest-dist.exe is the program meant for submission, but winetest-dist.exe.so should be able to submit as well.
make dist make: *** No rule to make target `build.id', needed by `dist.res'. Stop.
For the built in wine, run with wine case, couldn't there be reasonable default values rather than reading them from a file?
That's exactly what we wanted to avoid. Submitted results should * not come from Wine but genuine Windows systems, and * be identifiable. So we decided to require some (small, one time) effort of people providing test suites. For what you are doing, make test seems worth consideration. If I guessed correctly. :)
What I am interested in seeing are the test results for both the wave and dsound tests on both windows and wine. These tests are highly hardware and os dependent and it's impossible to duplicate all the possible combinations. The fact that these tests work fine on windows and my system doesn't help the people that are complaining of problems on their systems. Why should winetest be restricted to windows only?
Robert Reif reif@earthlink.net writes:
For the built in wine, run with wine case, couldn't there be reasonable default values rather than reading them from a file?
That's exactly what we wanted to avoid. Submitted results should * not come from Wine but genuine Windows systems, and * be identifiable. So we decided to require some (small, one time) effort of people providing test suites. For what you are doing, make test seems worth consideration. If I guessed correctly. :)
[...] Why should winetest be restricted to windows only?
Well, it isn't. It's just we'd like to see some identification on the data published on the webpage. Moreover, the processing scripts are not prepared for reports coming from Wine, which would lead to confusion. It wouldn't be hard to fix, though, the report contains this information, but it's not presented to the reader.
So, just read the README in the source directory, create (and keep up to date) those pesky files and give it a go. But we'd rather not drown in unusable reports coming from people running every executable in the Wine tree, and that's the reason for not having defaults. We used to, btw.
If I still miss your point, and you don't find it hopeless, please try to explain the difficulty you experience once more.
Ferenc Wagner wrote:
Robert Reif reif@earthlink.net writes:
For the built in wine, run with wine case, couldn't there be reasonable default values rather than reading them from a file?
That's exactly what we wanted to avoid. Submitted results should * not come from Wine but genuine Windows systems, and * be identifiable. So we decided to require some (small, one time) effort of people providing test suites. For what you are doing, make test seems worth consideration. If I guessed correctly. :)
[...] Why should winetest be restricted to windows only?
Well, it isn't. It's just we'd like to see some identification on the data published on the webpage. Moreover, the processing scripts are not prepared for reports coming from Wine, which would lead to confusion. It wouldn't be hard to fix, though, the report contains this information, but it's not presented to the reader.
So, just read the README in the source directory, create (and keep up to date) those pesky files and give it a go. But we'd rather not drown in unusable reports coming from people running every executable in the Wine tree, and that's the reason for not having defaults. We used to, btw.
If I still miss your point, and you don't find it hopeless, please try to explain the difficulty you experience once more.
I would like to see winetest used for more than windows compatibility and wine regressions. I would like to see it used as a diagnostic tool for specific hardware and os combinations and specific system configurations. I made sure the wave and dsound tests try to list the specific hardware and drivers used to make identifying which hardware/driver combinations work and which don't. If no one runs these tests on wine because they are difficult to set up, then how will we ever get feedback except from bug reports. When diagnosing sound related problems in wine, the first step I recommend doing after verifying that sound works outside of wine is to run the wave and dsound regression tests (preferably in interactive mode) and provide the results.
Since most people probably don't use sound or don't care about it, we are not getting as much feedback as we could. Maybe what we need is a separate wine hardware compatibility test to test if your hardware is compatible with wine but I think winetest, while not created for that purpose, could be used that way. If sound doesn't work properly on someone's system but the don't use sound, we will not get a bug report from them. However if they run winetest, we will know it doesn't work and can then try to identify the problem, even if they don't know or care about it. It might even be interesting to optionally run winetest at installation time so we can tell them that what features of wine will and will not work on their system as they currently have it configured. Maybe we could add a test sound button to winecfg that runs the sound related tests. I just want to see sound tested on as many systems as possible so we can get it working reliably for everyone.
Robert Reif wrote:
or care about it. It might even be interesting to optionally run winetest at installation time so we can tell them that what features of wine will and will not work on their system as they currently have it configured.
Wow, I think this is an excellent idea!
regards, Jakob Eriksson
Robert Reif reif@earthlink.net writes:
I would like to see winetest used for more than windows compatibility and wine regressions. I would like to see it used as a diagnostic tool for specific hardware and os combinations and specific system configurations. [...]
Since most people probably don't use sound or don't care about it, we are not getting as much feedback as we could. [...] It might even be interesting to optionally run winetest at installation time so we can tell them that what features of wine will and will not work on their system as they currently have it configured.
Do you mean you'd like to wade through the installation reports of every people installing Wine? How would you tell which report belongs to whom? Anyway, your business, but I think we shouldn't mix those reports with those of the offical test suites that test writers use for reference. What default values do you think would serve for this purpose?
OTOH if you'd like to see winetest reports from somebody who complains, the -o option may come to your help, as you could ask for the log file mailed to you. But then you could as well do without winetest, of course.
I suggest you come up with a concrete proposal we can discuss. Winetest is free software (and still incomplete), you can change it or have it changed; I'm willing to help out.
I think I've found the problem, mingw-w32api does not have mscms With this patch my build runs successfully
However, I currently have another issue..sourceforge seems to have made some kind of minor change to their site that breaks sfpublish.
As I'm not going to have much time to hack on sfpublish, and it doesn't seem its very maintained, a possible quick fix could be to stick the files onto the sourceforge shell which would be accessable through wine.sourceforge.net/winetest.zip or something similar..any thoughts?
On Monday 11 October 2004 05:57 am, Ferenc Wagner wrote:
only. Unfortunately, cross-building seems broken ATM. Kevin, Paul, can you comment on this? I remember Paul sending a report to wine-devel about a week ago, do we still suffer from the same problem?
On Friday 15 October 2004 05:40, Kevin Koltzau wrote:
I think I've found the problem, mingw-w32api does not have mscms With this patch my build runs successfully
Yes, I probably should have mentioned here that there's a new set of MinGW RPMS on this page:
that will allow you cross build all Wine tests. Debianers could use alien, source installers could extract the patches from the source RPM.
If someone wants to maintain Debian packages, send them to me and I will happily put them on page. And maybe I should make the patches available for download seperately as well.
-Hans
On czwartek 14 październik 2004 11:40 pm, Kevin Koltzau wrote:
I think I've found the problem, mingw-w32api does not have mscms With this patch my build runs successfully
An updated crossmingw32-platform-0.10 that includes this patch is being uploaded to http://www.ibib.waw.pl/~winnie
Cheers, Kuba Ober
-
Dmitry Timoshkov -
Ferenc Wagner -
Hans Leidekker -
Jakob Eriksson -
Kevin Koltzau -
Kuba Ober -
Paul Millar -
Robert Reif