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.
