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
|
|
|
|
|
|
|
|
# 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++"
|
2012-03-25 22:55:03 +00:00
|
|
|
;;
|
|
|
|
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=
|
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
|
|
|
|
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
|
2012-03-25 22:55:03 +00:00
|
|
|
echo Writing config-mingw.mk
|
|
|
|
echo CXX=$MINGW_GPP > config-mingw.mk
|