Andy Wingo writes:

>> +Upstream status: not yet presented upstream.
>> +
>> +--- libtool-2.4.6/build-aux/ltmain.in~ 2015-02-06
>> 13:57:56.000000000 +0100
>> ++++ libtool-2.4.6/build-aux/ltmain.in 2016-05-06 07:46:29.425142546
>> +0200
>> +@@ -3658,12 +3658,10 @@
>> + #if defined _MSC_VER
>> + # define setmode _setmode
>> +-# define stat    _stat
>> + # define chmod   _chmod
>> + # define getcwd  _getcwd
>> + # define putenv  _putenv
>> + # define S_IXUSR _S_IEXEC
>> + #elif defined __MINGW32__
>> + # define setmode _setmode
>> +-# define stat    _stat
>> + # define chmod   _chmod
>> + # define getcwd  _getcwd
>
> This doesn't look right to me.  Stat was actually the first of this set
> to be added to the weird define list, via:

Ah, two problems here.  I did not want to patch the _MSC_VER bit and
wanted to /add/ lstat rather than remove stat.  (I have tested quite
some variants until before everything worked; the comment actually
advertises this

    redefining stat also impacts struct stat, breaking lstat's signature.  That is
    fixed be #define'ing lstat along.)

I now have

    @@ -3658,6 +3658,7 @@
     # define S_IXUSR _S_IEXEC
     #elif defined __MINGW32__
     # define setmode _setmode
    +# define lstat   _lstat
     # define stat    _stat
     # define chmod   _chmod
     # define getcwd  _getcwd

(changed both instances of this)

>     commit 781fc82e1b2bceaa5c55388d6ab1d1744663f992
>     Author: Peter Rosin <peda@lysator.liu.se>
>     Date:   Sun Jul 22 17:57:10 2007 +0000
>
>         * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src): Add
>         support for Microsoft Visual C. Also, older MinGW versions
>         seem to need stdint.h to find intptr_t.

Wow, you looked it up for me.  Hmm.

> And there does appear to exist "struct _stat" in the API
> (https://msdn.microsoft.com/en-us/library/14h5k7ff.aspx).

Yes, there is _stat, and that's the problem because functions _stat
_lstat use struct _stat, while all other functions use struct stat.

> Does it mean that "lstat" is coming from somewhere else (i.e. not the
> system libc), expecting to have a "struct stat" as an argument?  I
> don't know very much about this stuff but this change looks fishy to
> me.

I have added lstat as a patch to mingw-w64.

We were discussing the readline patch I used that just #ifdef'd-out
apparently missing symbols such as SIGHUP..SIGALRM, S_ISGUID...and
S_SFLNK.  I started looking into porting Bash and found it uses such
symbols that are missing in MinGW without #ifdef guards in many places.

I decided it would make sense to try adding these symbols mingw's
signal.h and sys/stat.h, instead of patching all patches that use them.
On strange thing here is that I found some signals are include in MinGW
but only behind an #ifdef _POSIX flag.  That puzzles me, aren't we
creating (limited) POSIX compatibility here, why limit it further using
a flag...?

Anyway, adding these symbols and using -D_POSIX works nicely for
readline, no patch needed anymore and it helps a lot with bash.

Then, I tried to build ncurses with the cross-libtool.  I found that
when libtool finds S_ISLNK is defined, it decides to use lstat.  So
instead of patching libtool, I went back to mingw-w64 and added lstat
variants alongside stat

    +#define _lstat32 _lstat
     #define _stat32 _stat

    +#define _lstat _lstat64i32
     #define _stat _stat64i32

     int __cdecl stat(const char *_Filename,struct stat *_Stat);
    +static inline int __cdecl lstat(const char *_Filename,struct stat *_Stat){return stat(_Filename, _Stat);}

       _CRTIMP int __cdecl _stat32(const char *_Name,struct _stat32 *_Stat);
    +  static inline int __cdecl _lstat32(const char *_Name,struct _stat32 *_Stat) {return _stat32(_Name, _Stat);}

That also helps with other packages that use lstat without testing (eg,
flex) and seems to be the right thing?

However, now libtool's redefinition of stat without redefining lstat

    # define stat    _stat

breaks lstat here

    +static inline int __cdecl lstat(const char *_Filename,struct stat *_Stat){return stat(_Filename, _Stat);}

Does that make sense?

Greetings,
Jan