[bug #57406] mbsinit.c fails to compile with GCC 9.2.0 on MinGW-w64 (i686)

[Martin Storsjö]

Follow-up Comment #4, bug #57406 (project gettext):

I'm continuing this discussion here, even though this matter is entirely
between gnulib and mingw-w64 now, not related to gettext itself.

[comment #1 comment #1:]
> I see recent relevant patches here:
> 
> https://sourceforge.net/p/mingw-w64/mailman/message/36795394/
> https://sourceforge.net/p/mingw-w64/mailman/message/36878685/
> 
> This area seems to be in active development on the mingw side.
> 
> Please tell us when there is a new release of mingw-w64 that contains these
changes (stabilized).

Well, the first patch is included in the v7.0.0 stable release from November.

The second patch was a response to this issue, but it isn't merged yet.

I'll try to summarize the situation:

- Since a couple years, mingw-w64 can be configured to use the new Windows 10
UCRT instead of the old (actively discouraged by microsoft) msvcrt.dll

- In msvcrt.dll, mbstate_t is a plain int, but in UCRT it's a struct

- In mingw.org distributions, mbsinit always returns 1, while mingw-w64 since
the inception (or at least from the initial commit in the current VCS, from
2007), have a functional mbsinit similar to what gnulib provides

- Currently, if building gettext and the bundled gnulib with UCRT
headers/libs, the build does succeed. (I don't know what actually differs in
Tom's setup compared to mine.) Currently with UCRT, there's only a header
inline definition of mbsinit, while with msvcrt.dll, there's a mingw-provided
extern mbsinit in one of the libraries that are linked in by default.

- gnulib decides to always replace the mbsinit function when targeting mingw,
as it historically used to be broken (always returning 1)

- As the UCRT setup lacks an mbsinit function in the libraries, gnulib's
mbrtowc.m4 will also decide to replace the mbstate_t type with a typedef int,
http://git.savannah.gnu.org/cgit/gnulib.git/tree/m4/mbrtowc.m4#n104. This
saves the situation, as then gnulib's mbsinit replacement works with gnulib's
mbstate_t type, which works.

- If I make mingw-w64 provide an mbsinit function in libraries for UCRT (the
second patch above), the gnulib build breaks, as mbrtowc.m4 above won't decide
to replace mbstate_t any longer, but still building gnulib's mbsinit (which
assumes that mbstate_t is a plain integer).

I don't know off-hand what the best path forward would be. If replacing
mbsinit would be tied to actually detecting it (i.e. ignoring the situation
with mingw.org toolchains where it always returns 1), I believe things would
work, as mbrtowc.m4 either would force replacing mbstate_t along with mbsinit
(which works), or rely on the mingw-w64 provided mbsinit (not trying to build
gnulib's mbsinit).

If you want to try it out for yourselves, I can provide a prebuilt toolchain
with new enough mingw headers/libs to showcase the issue. If you're interested
in trying that, would you want a linux or windows based one?

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?57406>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/