Re: Status of the MSYS/MSVC port

[Peter Rosin]

Den 2009-01-28 04:25 skrev Charles Wilson:
> Peter Rosin wrote:
>
> > 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). It's the second time through the loop that fails, when
> > restrictive_flags='-std=c89 -Wall -Werror' (an attempt to execute the
> > missing usea.exe). The root cause is that when linking, the compile of
> > the wrapper fails with various implicitly declared (or undeclared)
> > identifiers -> usea.exe goes MIA. But that test behaves the exact same
> > way on a pure libtool from git master, so move on, nothing to see
> > here...
>
> Odd. I thought one of my recent patches (git diff 0aef3579..6631e515)
> fixed those.  Do we need to add more stuff
>
> /* declarations of non-ANSI functions */
> #if defined(__MINGW32__)
> # ifdef __STRICT_ANSI__
> <<<<< HERE? >>>>>>

Maybe, here are the errors:

../../tests/cwrapper.at:76: $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o 
usea$EXEEXT usea.$OBJEXT liba.la
stderr:
./.libs/lt-usea.c: In function `main':
./.libs/lt-usea.c:221: warning: implicit declaration of function `_setmode'
./.libs/lt-usea.c:370: warning: implicit declaration of function `_spawnv'
./.libs/lt-usea.c:370: error: `_P_WAIT' undeclared (first use in this function)
./.libs/lt-usea.c:370: error: (Each undeclared identifier is reported only once
./.libs/lt-usea.c:370: error: for each function it appears in.)
./.libs/lt-usea.c: In function `check_executable':
./.libs/lt-usea.c:421: error: storage size of 'st' isn't known
./.libs/lt-usea.c:428: warning: implicit declaration of function `_stat'
./.libs/lt-usea.c:429: error: `S_IXUSR' undeclared (first use in this function)
./.libs/lt-usea.c:421: warning: unused variable `st'
./.libs/lt-usea.c: In function `make_executable':
./.libs/lt-usea.c:439: error: storage size of 'st' isn't known
./.libs/lt-usea.c:448: warning: implicit declaration of function `_chmod'
./.libs/lt-usea.c:448: error: `S_IXUSR' undeclared (first use in this function)
./.libs/lt-usea.c:439: warning: unused variable `st'
./.libs/lt-usea.c: In function `find_executable':
./.libs/lt-usea.c:521: warning: implicit declaration of function `_getcwd'
./.libs/lt-usea.c:521: warning: comparison between pointer and integer
./.libs/lt-usea.c:546: warning: comparison between pointer and integer
C:\MinGW\bin\strip.exe: ./usea.exe: No such file or directory
./libtool: $func_ltwrapper_scriptname_result: ambiguous redirect
stdout:
libtool: link: gcc -g -O2 -std=c89 -Wall -Werror -o .libs/usea.exe usea.o  
./.libs/liba.dll.a -L/foo

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
#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 */
int _stat (const char *, struct _stat *);
#ifndef S_IXUSR /* just in case */
# define        S_IXUSR         _S_IXUSR
#endif
int _chmod (const char *, int);
char * _getcwd (char *, int);

But IMHO, the struct _stat declaration is horrible to have in the
code. Shouldn't we just #undef __STRICT_ANSI__ before we include
anything or something? It's not as if that define helps...

Cheers,
Peter