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: Bruno Haible
Subject: [bug #63371] build fails on MinGW due to missing gnulib close module
Date: Thu, 22 Jun 2023 03:54:49 -0400 (EDT)

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


> Wine is not involved in cross-compilation. Only a compiler and Mingw headers
and import libraries are.

Oh, you are talking about an environment where
- all Autoconf tests that involve AC_RUN_IFELSE are guesses with manually
predetermined results,
- it is not possible to run "make check"?

As a builder, you have not the slightest clue about the reliability of the
resulting binaries. I don't even want to think about such environments.

> 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.

True. But since the GNU Build system is based on a POSIX 'make' program and a
POSIX 'sh' program, and native Windows doesn't have these, they must come from
somewhere. Either from MSYS2, which is a minified Cygwin and thus has the same
problem that you want to avoid; or from a Linux-based cross-compilation
environment with Wine; or from WSL. Maybe someone knows whether WSL is usable
for such cross-compilation?

> 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.

While this is theoretically possible, I think/hope I'm avoiding most of these
pitfalls because:
- I also run 32-bit mingw compilations on 64-bit cygwin; the object formats of
32-bit mingw and 64-bit cygwin are not the same.
- I routinely check the "dumpbin /imports" of binaries.
- Most of the Autoconf tests use AC_LINK_IFELSE and AC_RUN_IFELSE, which use
the correct compiler.



    _______________________________________________________

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]