[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #57406] mbsinit.c fails to compile with GCC 9.2.0 on MinGW-w64 (i68
[bug #57406] mbsinit.c fails to compile with GCC 9.2.0 on MinGW-w64 (i686)
Mon, 16 Dec 2019 16:44:50 -0500 (EST)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.2 Safari/605.1.15
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:
> 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
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,
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
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:
Message sent via Savannah