This bug was already fixed 5 months ago, but AFAICT MinGW.org hasn't
released it yet. MinGW-w64 is unaffected, as is the MinGW compiler
packaged with Cygwin.
Now that the InputHandler thread blocks with select, in addition to the
main thread that also blocks with select, winpty has hit a bug in the
original MSYS where select returns EAGAIN. select is not supposed to fail
with that error (EAGAIN doesn't make much sense as a select error). Add
a workaround just for the original MSYS.
* Remove GIT_REVPARSE_WORKS, which is never used
* Rename the shell variables {UNIX,MINGW}_GPP to {UNIX,MINGW}_CXX to
match the config.mk variable names.
There is a "version suffix" that defaults to "-dev". A maintainer could
change the suffix (or remove it) by invoking make:
make BUILD_SUFFIX=-foo
make BUILD_SUFFIX=
It can also be changed in gyp builds:
gyp winpty.gyp --depth=1 -D BUILD_SUFFIX=-foo
gyp winpty.gyp --depth=1 -D BUILD_SUFFIX=
If git cannot be executed, the string "none" is used for the commit hash.
* This change reduces the total build time from about 14 seconds to about
9 seconds on my computer.
Also:
* Consolidate all the intermediate files into the build directory to
reduces clutter.
* Allow specifying UNIX_ADAPTER_EXE to make. Perhaps this will be helpful
to the MSYS2 fork, which renames console.exe to winpty.exe. (I like
the renaming, but I don't know about the other winpty users. Maybe
I'll make the change after I've put out another stable release...)
* Rename the WINPTY define to COMPILING_WINPTY_DLL define. The longer
name is clearer. I define the macro inside libwinpty/winpty.cc, so the
build system no longer needs to. (I removed the define from
winpty.gyp.)
* Consolidate config-unix.mk and config-mingw.mk into config.mk. The
separation was previously necessary because each file had a conflicting
definition of CXX.
* Rename the UNIX_LDFLAGS_STATIC_LIBSTDCXX macro to UNIX_LDFLAGS_STATIC,
because libstdc++ isn't the only thing I'm linking statically.
* MSYS is 32-bit only.
* MSYS2 and Cygwin are either 32-bit or 64-bit. On 64-bit MSYS2/Cygwin,
we use the same architecture for all generated binaries.
* Prefer mingw-w64 to mingw. mingw-w64 seems to be more up-to-date.
It is the only option for 64-bit Windows, so stop looking for
x86_64-pc-mingw32-g++.
* Also pass -static when linking binaries. Otherwise, a pthreads DLL
is linked dynamically.
* At least for now, I'm shipping Cygwin/MSYS binaries. On Cygwin (but
not MSYS), the console.exe executable previously linked dynamically
to cyggcc_s-1.dll and cygstdc++-6.dll.
Linking dynamically with cygstdc++-6.dll seems risky for a binary
not distributed by Cygwin, because G++'s Windows ABI is unstable, at
least as of G++ 4.7, which turned on the __thiscall calling
convention. If a binary I ship ever comes into contact with a
4.7-versioned cygstdc++-6.dll, then my binary will (very likely)
segfault.
So far, I've only observed this ABI incompatibility with MinGW,
where a sufficiently upgraded MinGW configuration comes with a
libstdc++-6.dll that is completely incompatible with every previous
libstdc++-6.dll, so that every program built against the older
libstdc++-6.dll segfaults immediately. For now, Cygwin seems stuck
at G++ 4.5, and my impression (possibly incorrect), is that G++'s
Windows ABI was stable prior to 4.7. I think G++'s Linux ABI is
stable. Presumably Cygwin will eventually update its compiler,
though, so it makes sense to fix the problem early.
I believe I originally chose to dynamically link the libraries
because it was the default behavior, and I was afraid that a
non-default option would break something. It turns out that
linking statically with cygstdc++-6 *does* break something -- it
causes linker errors if the code uses std::cerr. The workaround
is not to use std::cerr. This is not a problem for the
unix-adapter, which already has to put up with MSYS' gimpy G++ 3.4
compiler.
* Move the Cygwin/MSYS detection logic from config-*.mk into this new
script.
* Recognize either the 32-bit MinGW or the 32-bit MinGW-w64 compiler
driver for Cygwin.
