2012-03-25 22:55:03 +00:00
|
|
|
#!/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
|
|
|
|
|
2015-09-30 08:34:16 +00:00
|
|
|
# Link parts of the Cygwin binary statically to aid in redistribution? The
|
|
|
|
# binary still links dynamically against the main DLL. The MinGW binaries are
|
|
|
|
# also statically linked and therefore depend only on Windows DLLs. I started
|
|
|
|
# linking the Cygwin/MSYS binary statically, because G++ 4.7 changed the
|
|
|
|
# Windows C++ ABI.
|
|
|
|
UNIX_LDFLAGS_STATIC_LIBSTDCXX='-static -static-libgcc -static-libstdc++'
|
|
|
|
|
2012-03-25 22:55:03 +00:00
|
|
|
# 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)
|
2015-09-30 08:34:16 +00:00
|
|
|
echo 'uname -m identifies an i686 environment.'
|
2014-09-01 05:37:26 +00:00
|
|
|
UNIX_GPP=i686-pc-cygwin-g++
|
2015-09-30 08:34:16 +00:00
|
|
|
MINGW_GPP="i686-w64-mingw32-g++ i686-pc-mingw32-g++"
|
2014-09-01 05:37:26 +00:00
|
|
|
;;
|
|
|
|
x86_64)
|
2015-09-30 08:34:16 +00:00
|
|
|
echo 'uname -m identifies an x86_64 environment.'
|
2014-09-01 05:37:26 +00:00
|
|
|
UNIX_GPP=x86_64-pc-cygwin-g++
|
2015-09-30 08:34:16 +00:00
|
|
|
MINGW_GPP=x86_64-w64-mingw32-g++
|
2014-09-01 05:37:26 +00:00
|
|
|
;;
|
|
|
|
*)
|
|
|
|
echo 'Error: uname -m did not match either i686 or x86_64.'
|
|
|
|
exit 1
|
|
|
|
;;
|
|
|
|
esac
|
2012-03-25 22:55:03 +00:00
|
|
|
;;
|
2015-09-30 08:34:16 +00:00
|
|
|
MSYS*|MINGW*)
|
|
|
|
# MSYS2 notes:
|
|
|
|
# - MSYS2 offers two shortcuts to open an environment:
|
|
|
|
# - MinGW-w64 Win32 Shell. This env reports a `uname -s` of
|
|
|
|
# MINGW32_NT-6.1 on 32-bit Win7. The MinGW-w64 compiler
|
|
|
|
# (i686-w64-mingw32-g++.exe) is in the PATH.
|
|
|
|
# - MSYS2 Shell. `uname -s` instead reports MSYS_NT-6.1.
|
|
|
|
# The i686-w64-mingw32-g++ compiler is not in the PATH.
|
|
|
|
# - MSYS2 appears to use MinGW-w64, not the older mingw.org.
|
|
|
|
# MSYS notes:
|
|
|
|
# - `uname -s` is always MINGW32_NT-6.1 on Win7.
|
|
|
|
echo 'uname -s identifies an MSYS/MSYS2 environment.'
|
2012-03-25 22:55:03 +00:00
|
|
|
IS_MSYS=1
|
2015-09-30 08:34:16 +00:00
|
|
|
case $(uname -m) in
|
|
|
|
i686)
|
|
|
|
echo 'uname -m identifies an i686 environment.'
|
|
|
|
UNIX_GPP=i686-pc-msys-g++
|
|
|
|
MINGW_GPP='i686-w64-mingw32-g++.exe mingw32-g++'
|
|
|
|
if echo "$(uname -r)" | grep '^1[.]' > /dev/null; then
|
|
|
|
# The MSYS-targeting compiler for the original 32-bit-only
|
|
|
|
# MSYS does not recognize the -static-libstdc++ flag, and
|
|
|
|
# it does not work with -static, because it tries to link
|
|
|
|
# statically with the core MSYS library and fails.
|
|
|
|
#
|
|
|
|
# Distinguish between the two using the major version
|
|
|
|
# number of `uname -r`:
|
|
|
|
#
|
|
|
|
# MSYS uname -r: 1.0.18(0.48/3/2)
|
|
|
|
# MSYS2 uname -r: 2.0.0(0.284/5/3)
|
|
|
|
#
|
|
|
|
# This is suboptimal because MSYS2 is not actually the
|
|
|
|
# second version of MSYS--it's a brand-new fork of Cygwin.
|
|
|
|
#
|
|
|
|
UNIX_LDFLAGS_STATIC_LIBSTDCXX=
|
|
|
|
fi
|
|
|
|
;;
|
|
|
|
x86_64)
|
|
|
|
echo 'uname -m identifies an x86_64 environment.'
|
|
|
|
UNIX_GPP=x86_64-pc-msys-g++
|
|
|
|
MINGW_GPP=x86_64-w64-mingw32-g++
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
echo 'Error: uname -m did not match either i686 or x86_64.'
|
|
|
|
exit 1
|
|
|
|
;;
|
|
|
|
esac
|
2012-03-25 22:55:03 +00:00
|
|
|
;;
|
|
|
|
*)
|
2012-03-26 02:24:39 +00:00
|
|
|
echo 'Error: uname -s did not match either CYGWIN* or MINGW*.'
|
|
|
|
exit 1
|
2012-03-25 22:55:03 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
# Search the PATH and pick the first match.
|
|
|
|
findTool "Cygwin/MSYS G++ compiler" "$UNIX_GPP"
|
|
|
|
UNIX_GPP=$FINDTOOL_OUT
|
2015-09-30 08:34:16 +00:00
|
|
|
findTool "MinGW G++ compiler" "$MINGW_GPP"
|
2012-03-25 22:55:03 +00:00
|
|
|
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
|
2012-03-25 22:55:03 +00:00
|
|
|
echo Writing config-mingw.mk
|
|
|
|
echo CXX=$MINGW_GPP > config-mingw.mk
|