bug-gettext
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #63371] build fails on MinGW due to missing gnulib close module


From: Vaclav Slavik
Subject: [bug #63371] build fails on MinGW due to missing gnulib close module
Date: Thu, 22 Jun 2023 02:43:00 -0400 (EDT)

Follow-up Comment #8, bug #63371 (project gettext):

[comment #7 comment #7:]
> The problem with x86_64-w64-mingw32 in a build environment of type
x86_64-unknown-linux-gnu is that it adds another component, namely Wine, to
the mix. Which adds a source of complexity/bugs

Wine is not involved in cross-compilation. Only a compiler and Mingw headers
and import libraries are. It actually avoids an extra component the supported
build requires, namely Cygwin. 

Your preferred environment is conceptually similar: you're cross-compiling
from Cygwin to Mingw runtime, only without the added protection of binary
formats being incompatible and not executable on the host. As Cygwin and Mingw
both use Windows PE format, it's all too easy to accidentally pull in a part
of Cygwin (been there, done that too many times) or inadvertently run a
runtime check against Cygwin instead of Mingw target. Indeed, I suspect
something of the kind may be happening here with the close module, which is
why it fails in native and cross-compile-from-linux environments, but not in
cross-compile-from-cygwin one. 

By the way: this seems to have affected mlocati's binaries (the ones you link
to) too: they used cross-compilation setup and per
https://github.com/mlocati/gettext-iconv-windows/issues/14 gave up on trying
to build 0.21.1 in an "official" Cygwin environment.

> And what is it worth if there is the possibility that the resulting binaries
work fine in this environment, but not in real Windows?

For what it's worth, I couldn't agree more; this is precisely the motivation
for avoiding Cygwin... When only Mingw headers and libraries are involved,
you're guaranteed that the output is compatible with real (Cygwin-less)
Windows. 

> There is no continuum of operating systems between POSIX and Windows. It's
two isolated groups of OSes:

I don't think I of all people need this explained :) My point was that the
issue is in the check and is likely related to (cross-)compilation and not
Windows per se.

> If you find it worth fixing, then feel free to spend the effort on it. I
don't want to spend effort on it, 

Of course, understood.


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]