Re: Status of the MSYS/MSVC port

[Peter Rosin]

Den 2009-01-28 16:13, skrev Charles Wilson:
> Peter Rosin wrote:
> > Maybe, here are the errors:
> >
> > So, I guess these declarations should do it (untested):
> >
> > int _setmode (int, int);
> > int _spawnv (int, const char *, const char * const *);
> > #ifndef _P_WAIT /* just in case */
> > # define _P_WAIT        0
> > #endif
>
> _P_WAIT is guarded in MSVC's process.h by #ifndef _POSIX_ (as opposed to
> __STRICT_ANSI__). In MinGW's process.h, it is not guarded at all (but
> P_WAIT is guarded by _NO_OLDNAMES).
>
>
> > #ifndef _STAT_DEFINED
> > struct _stat
> > {
> >     _dev_t    st_dev;        /* Equivalent to drive number 0=A 1=B ... */
> >     _ino_t    st_ino;        /* Always zero ? */
> >     _mode_t    st_mode;    /* See above constants */
> >     short    st_nlink;    /* Number of links. */
> >     short    st_uid;        /* User: Maybe significant on NT ? */
> >     short    st_gid;        /* Group: Ditto */
> >     _dev_t    st_rdev;    /* Seems useless (not even filled in) */
> >     _off_t    st_size;    /* File size in bytes */
> >     time_t    st_atime;    /* Accessed date (always 00:00 hrs local
> >                  * on FAT) */
> >     time_t    st_mtime;    /* Modified time */
> >     time_t    st_ctime;    /* Creation time */
> > };
> > #endif /* _STAT_DEFINED */
>
> Something is not right here. I took a look at the pre-preocessed output
> from mingw-gcc -std=c89 -E lt-foo.c, and both 'struct stat' and 'struct
> _stat' were declared. Further, looking at the MinGW sys/stat.h, I can't
> see where any of the compile flags we are using -- even the restrictive
> ones -- would exclude those declarations.
>
> Are you using the MSVC include files here? I thought the test case was:

I don't think I do...

I'll get back when I hace inspected some preprocessor output...

> "On MSYS/MinGW, stresstest.at now passes when "Run tests with low
> max_cmd_len", that fails on git master. On the other hand, "cwrapper for
> uninstalled executables" fails at cwrapper.at:78 (both with and without
> low max_cmd_len)."
>
> MSYS/MinGW, *not* msvc?

Yes.

> Now, if there are MSVC problems, we'll have to fix those, too. But I
> want to be clear on exactly what we're discussing...

No problems on MSVC (perhaps because we're not trying its -Werror switch,
i.e. -WX).

Cheers,
Peter