Commit Graph

5 Commits

Author SHA1 Message Date
Ryan Prichard
2ecc596f8b Update winpty to work with MSYS, MSYS2, and Cygwin.
* 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.
2015-09-30 03:34:16 -05:00
Haoming Zhu
793ff925a2 Fix configure for 64-bit Cygwin. 2014-09-01 13:37:26 +08:00
Ryan Prichard
549472ec78 unix-adapter: Link statically with cyggcc_s-1.dll and cygstdc++-6.dll.
* 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.
2012-12-20 04:07:55 -08:00
Ryan Prichard
46701caf39 Mark configure as executable and exit if uname -s isn't recognized. 2012-03-25 19:24:39 -07:00
Ryan Prichard
82cfc70d98 Create a configure script.
* 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.
2012-03-25 15:55:03 -07:00