winpty/configure

100 lines
3.3 KiB
Plaintext
Raw Normal View History

#!/bin/bash
#
# Copyright (c) 2011-2012 Ryan Prichard
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to
# deal in the Software without restriction, including without limitation the
# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
# sell copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
# IN THE SOFTWARE.
#
# findTool(desc, commandList)
#
# Searches commandLine for the first command in the PATH and returns it.
# Prints an error and aborts the script if no match is found.
#
FINDTOOL_OUT=""
function findTool {
DESC=$1
OPTIONS=$2
for CMD in ${OPTIONS}; do
if (which $CMD &>/dev/null) then
echo "Found $DESC: $CMD"
FINDTOOL_OUT="$CMD"
return
fi
done
echo "Error: could not find $DESC. One of these should be in your PATH:"
for CMD in ${OPTIONS}; do
echo " * $CMD"
done
exit 1
}
IS_CYGWIN=0
IS_MSYS=0
# Detect the environment -- Cygwin or MSYS.
case $(uname -s) in
CYGWIN*)
echo 'uname -s identifies a Cygwin environment.'
IS_CYGWIN=1
2014-09-01 05:37:26 +00:00
case $(uname -m) in
i686)
echo 'uname -m identifies a i686 environment.'
UNIX_GPP=i686-pc-cygwin-g++
MINGW_GPP="i686-pc-mingw32-g++ i686-w64-mingw32-g++"
;;
x86_64)
echo 'uname -m identifies a x86_64 environment.'
UNIX_GPP=x86_64-pc-cygwin-g++
MINGW_GPP="x86_64-pc-mingw32-g++ x86_64-w64-mingw32-g++"
;;
*)
echo 'Error: uname -m did not match either i686 or x86_64.'
exit 1
;;
esac
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-12 11:35:41 +00:00
UNIX_LDFLAGS_STATIC_LIBSTDCXX="-static-libgcc -static-libstdc++"
;;
MINGW*)
echo 'uname -s identifies a MSYS environment.'
IS_MSYS=1
UNIX_GPP=i686-pc-msys-g++
MINGW_GPP=mingw32-g++
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-12 11:35:41 +00:00
# The MSYS compiler does not recognize -static-libstdc++. There is a
# msys-1.0.dll, but no gcc or stdc++ DLL.
UNIX_LDFLAGS_STATIC_LIBSTDCXX=
;;
*)
echo 'Error: uname -s did not match either CYGWIN* or MINGW*.'
exit 1
;;
esac
# Search the PATH and pick the first match.
findTool "Cygwin/MSYS G++ compiler" "$UNIX_GPP"
UNIX_GPP=$FINDTOOL_OUT
findTool "32-bit MinGW G++ compiler" "$MINGW_GPP"
MINGW_GPP=$FINDTOOL_OUT
# Write config files.
echo Writing config-unix.mk
echo CXX=$UNIX_GPP > config-unix.mk
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-12 11:35:41 +00:00
echo LDFLAGS_STATIC_LIBSTDCXX=$UNIX_LDFLAGS_STATIC_LIBSTDCXX >> config-unix.mk
echo Writing config-mingw.mk
echo CXX=$MINGW_GPP > config-mingw.mk