Re: Broken cross-build, again.

[Paul Vriens]

On Wed, 2005-02-09 at 16:59, Paul Millar wrote:
> I haven't worked on any of winetest's innards, so this is largely 
> guess work...
>
> On Wednesday 09 February 2005 13:22, you wrote:
> > If I run winetest-200502091000-paul-mingw manually on my win98 box
> > I get several messages "Can't parse subtests output of" for the
> > following tests [...]
> > just before the tests actually start.
>
> My guess is that winetest is attempting to run these tests, but that 
> they are dying straight away, with some error message.  This error 
> message is not the expected output, hence the error messsage.
>
> [...]
> > Does this mean that we have a deeper lying problem?
>
> Yes, obviously!  The tests are failing and we have no mechanism for 
> detecting this.  This, in itself, is a bug.
> > Or just that 
> > more tests are somehow not correct (in combination with mingw)?
>
> I've bundled the individual tests in:
>   http://www.astro.gla.ac.uk/users/paulm/WRT/winetest-bin-20050209.zip
> (its some 2.6MiB in size, though)
>
> I image you should be able to run the shlwapi test individually, which 
> should help narrow down the cause.
>
> HTH,
>
> Paul.
> Hi Paul,

I've included wine-devel again as this must touch others as well.

I wasn't able to run the shlwapi tests on my win98 box, by itself.
Running this gives an error box:

The SHLWAPI_.EXE file is
linked to missing export SHLWAPI.DLL:PathIsValidCharA

and just for completeness sake:

dsound:

...
linked to missing export DSOUND.DLL:DirectSoundCreate8

mlang:

...
linked to missing export NTDLL.DLL:atoi

msvcrtd:

A required .DLL, MSVCRTD.DLL, was not found

ole32:

...
linked to missing export NTDLL.DLL:atoi

Cheers,

Paul Vriens.

Broken cross-build, again.

[Ferenc Wagner]

> > > If I run winetest-200502091000-paul-mingw manually on my win98 box
> > > I get several messages "Can't parse subtests output of" for the
> > > following tests [...]
> > > just before the tests actually start.

In the first round winetest runs all the individual test
executables to find out the names of subtests they contain.
In case of a failure it obiously has no way to run those
tests, so they are skipped.  You have the freedom the run
the problematic executables manually and find out more.
Winetest could be massaged to include the unparsable output
in the report, but it didn't seem worth it, as most of the
time it means that the test doesn't apply for the given
system (no such DLL installed).
-- 
Feri.

Broken cross-build, again.

[Paul Millar]

On Wednesday 09 February 2005 16:57, Ferenc Wagner wrote:
> In the first round winetest runs all the individual test
> executables to find out the names of subtests they contain.
> In case of a failure it obiously has no way to run those
> tests, so they are skipped.  You have the freedom the run
> the problematic executables manually and find out more.

To me it seems silly to blanket accept broken programs.  Known 
exclusions could be catered for such as ntdll tests on a W95 box 
(those fail, right?) either client-side (i.e. within winetest.exe) or 
server-side.

The current situation supposes that the person debugging the problem 
has access to the Win box that generated the fault, and so can 
recreate the problem by running the original xxx_test.exe executable.

By reporting back the error, someone can fix it without needing the 
specific version of Win98 that demonstrated the error.

Paul
(just my 2 euro-cent worth ;^)

Broken cross-build, again.

[Stefan Leichter]

Am Mittwoch, 9. Februar 2005 17:16 schrieb Paul Vriens:
> On Wed, 2005-02-09 at 16:59, Paul Millar wrote:
> [snip]
>
> Hi Paul,
>
> I've included wine-devel again as this must touch others as well.
>
> I wasn't able to run the shlwapi tests on my win98 box, by itself.
> Running this gives an error box:
>
> The SHLWAPI_.EXE file is
> linked to missing export SHLWAPI.DLL:PathIsValidCharA
>
> and just for completeness sake:
>
> dsound:
>
> ...
> linked to missing export DSOUND.DLL:DirectSoundCreate8
>
> mlang:
>
> ...
> linked to missing export NTDLL.DLL:atoi
>
> msvcrtd:
>
> A required .DLL, MSVCRTD.DLL, was not found
>
> ole32:
>
> ...
> linked to missing export NTDLL.DLL:atoi
>
> Cheers,
>
> Paul Vriens.

Hello,

mlang.dll and ole32.dll can be linked against msvcrt.dll insted of ntdll (like 
in the attached patch). Will this cause problems?

Bye Stefan

PS: Is someone working on a fix for the missing import of shlwapi.dll? If 
nobody 'complains' I will make a patch tomorrow evening

Broken cross-build, again.

[Paul Millar]

On Wednesday 09 February 2005 21:55, Stefan Leichter wrote:
> Am Mittwoch, 9. Februar 2005 17:16 schrieb Paul Vriens:
> > mlang:
> > linked to missing export NTDLL.DLL:atoi
> > [...]
> > ole32:
> > linked to missing export NTDLL.DLL:atoi
> mlang.dll and ole32.dll can be linked against msvcrt.dll insted of
> ntdll (like in the attached patch). Will this cause problems?

Yes, and no.

If msvcrt.dll is available then this will solve the problem.  But 
(from vague memories) although msvcrt is available for W95/98, its by 
no means installed by default.  On Paul's machine, the 
msvcrt-specific tests are failing due to a lack of that DLL.

Really, someone should write a simple atoi() implementation and the 
tests link against the portable code.  This can't take more than ten 
minutes, right?

Cheers,

Paul.

Broken cross-build, again.

[Saulius Krasuckas]

* On Wed, 9 Feb 2005, Paul Millar wrote:
> * On Wednesday 09 February 2005 21:55, Stefan Leichter wrote:
> > * Am Mittwoch, 9. Februar 2005 17:16 schrieb Paul Vriens:
> > > mlang:
> > > linked to missing export NTDLL.DLL:atoi
> > > [...]
> > > ole32:
> > > linked to missing export NTDLL.DLL:atoi
> > mlang.dll and ole32.dll can be linked against msvcrt.dll insted of
> > ntdll (like in the attached patch). Will this cause problems?
>
> Yes, and no.
>
> If msvcrt.dll is available then this will solve the problem.  But 
> (from vague memories) although msvcrt is available for W95/98, its by 
> no means installed by default.  On Paul's machine, the 
> msvcrt-specific tests are failing due to a lack of that DLL.
>
> Really, someone should write a simple atoi() implementation and the
> tests link against the portable code.  This can't take more than ten
> minutes, right?

Is someone working on any atoi() implementation to use it in Winetest now?

Broken cross-build, again.

[Jacek Caban]

Saulius Krasuckas wrote:
> Is someone working on any atoi() implementation to use it in Winetest now?

Here you have:

int atoi(char* buf)
{
    int ret = 0;
    char *c = buf;

    if(*c == '-')
        c++;

    while(*c) {
        if(*c < '0' || *c > '9')
            return 0;
        ret = ret*10 + (*c++)-'0';
    }

    return *buf == '-' ? -ret : ret;
}

Jacek

Broken cross-build, again.

[Saulius Krasuckas]

* On Thu, 14 Apr 2005, Jacek Caban wrote:
> Saulius Krasuckas wrote:
> > Is someone working on any atoi() implementation to use it in Winetest now?
>
> Here you have:

It not me who doesn't have it.  It's a question: is anyone prepared patch
to solve this problem.  Just some etiquette, right?

And the second question is: should it go to the "include/wine/test.h" or
some separate header like a "include/wine/strings.h".
> int atoi(char* buf)
> {
>     int ret = 0;
>     char *c = buf;
>
> if(*c == '-')
>         c++;
>
> while(*c) {
>   ...
> }

BTW, Jacek, your implementation lacks ability to skip leading white-spaces
which isn't a case for __atoi64() and StrToInt()  already implemented by
Wine. ;-P

Broken cross-build, again.

[Jacek Caban]

Saulius Krasuckas wrote:
> * On Thu, 14 Apr 2005, Jacek Caban wrote:
> > Saulius Krasuckas wrote:
> > > Is someone working on any atoi() implementation to use it in Winetest now?
> >
> > Here you have:
>
> It not me who doesn't have it.  It's a question: is anyone prepared patch
> to solve this problem.  Just some etiquette, right?

Ok, sorry, it wasn't a good answer. I don't think anyone is working
on this as I didn't see any patch on wine-patches.
> And the second question is: should it go to the "include/wine/test.h" or
> some separate header like a "include/wine/strings.h".

wine/test.h doesn't seems to me to be a good place for it. Also,
as it's used only in tests, wine/strings.h doesn't need this. I think
the best place is the source of the test.
> > int atoi(char* buf)
> > {
> >    int ret = 0;
> >    char *c = buf;
> >
> > if(*c == '-')
> >        c++;
> >
> > while(*c) {
>
> ...
> > }
>
> BTW, Jacek, your implementation lacks ability to skip leading white-spaces
> which isn't a case for __atoi64() and StrToInt()  already implemented by
> Wine. ;-P

Yeah, you're right. It was just a half-minute exercise:)

Jacek

Broken cross-build, again.

[Paul Millar]

Hi guys,

On Thursday 14 Apr 2005 20:04, Saulius Krasuckas wrote:
> * On Thu, 14 Apr 2005, Jacek Caban wrote:
> > Saulius Krasuckas wrote:
> > > Is someone working on any atoi() implementation [...]
> > > Here you have:
> > > It not me who doesn't have it.  It's a question: is anyone prepared patch
> > > to solve this problem.  Just some etiquette, right?

Sure.

AFAIK, no one is working on it: up to this point, I certainly hadn't.
> And the second question is: should it go to the "include/wine/test.h" or
> some separate header like a "include/wine/strings.h".

I think really we want a separate module that can be linked in as part of the 
build process.  I've always thought (albeit secretly) that having functions 
inside include/wine/test.h is a bit of a hack.
> > int atoi(char* buf)
> > [...]
> > BTW, Jacek, your implementation lacks ability to skip leading white-spaces
> > which isn't a case for __atoi64() and StrToInt()  already implemented by
> > Wine. ;-P

Also:
  I wouldn't call the function atoi() -- it would only cause confusion.  
Although I must admit calling it winetest_atoi() is a bit of a mouthful.

  'fraid your code also doesn't handle text (of any type) after the numbers; 
c.f.
  http://www.astro.gla.ac.uk/users/paulm/test_atoi.c

HTH,

Paul.

Broken cross-build, again.

[Saulius Krasuckas]

* On Thu, 14 Apr 2005, Jacek Caban wrote:
> *Saulius Krasuckas wrote:
> > And the second question is: should it go to the "include/wine/test.h"
> > or some separate header like a "include/wine/strings.h".
>
> wine/test.h doesn't seems to me to be a good place for it. Also, as it's
> used only in tests, wine/strings.h doesn't need this. I think the best
> place is the source of the test.

* On Thu, 14 Apr 2005, Paul Millar wrote:
> I think really we want a separate module that can be linked in as part
> of the build process.  I've always thought (albeit secretly) that having
> functions inside include/wine/test.h is a bit of a hack.

So I see two ways to solve this:

1, writing winetest_atoi() inside a separate file (lets say atoi.c) and
duplicating it across some parts of the Winetest (mlang, ole32).

2, linking dinamycally these Winetest binaries to shlwapi.dll, which
implements StrToIntA() already:

| [s2(a)katleriai wine]$ grep -B15 -A1 WINAPI.*StrToIntA dlls/shlwapi/string.c
| /*************************************************************************
|  * StrToIntA    [SHLWAPI.@]
|  *
|  * Read a signed integer from a string.
|  *
|  * PARAMS
|  *  lpszStr [I] String to read integer from
|  *
|  * RETURNS
|  *   The signed integer value represented by the string, or 0 if no integer is
|  *   present.
|  *
|  * NOTES
|  *  No leading space is allowed before the number, although a leading '-' is.
|  */
| int WINAPI StrToIntA(LPCSTR lpszStr)
| {

Is the latter way acceptable, what does the crew think?
> 'fraid your code also doesn't handle text (of any type) after the
> numbers;  c.f.
>   http://www.astro.gla.ac.uk/users/paulm/test_atoi.c

Thanks for the test suite, Paul.

But how come, not all Winetest parts misses this import (NTDLL.DLL:atoi)?
Given the code:

| [s2(a)katleriai wine]$ grep -A16 int.*main\( include/wine/test.h 
| int main( int argc, char **argv )
| {
|     char *p;
| 
|     setvbuf (stdout, NULL, _IONBF, 0);
| 
|     winetest_argc = argc;
|     winetest_argv = argv;
| 
|     if ((p = getenv( "WINETEST_PLATFORM" ))) winetest_platform = p;
|     if ((p = getenv( "WINETEST_DEBUG" ))) winetest_debug = atoi(p);
|     if ((p = getenv( "WINETEST_INTERACTIVE" ))) winetest_interactive = atoi(p);
|     if ((p = getenv( "WINETEST_REPORT_SUCCESS"))) report_success = atoi(p);
|     if (!argv[1]) usage( argv[0] );
| 
|     return run_test(argv[1]);
| }

why isn't miss happening in every Winetest part?