2017-07-26 01:33:44 +03:00
|
|
|
#!/bin/bash
|
|
|
|
|
set -e -v
|
|
|
|
|
|
|
|
|
|
# This script is for building GN.
|
|
|
|
|
|
|
|
|
|
WORKSPACE=$HOME/workspace
|
|
|
|
|
COMPRESS_EXT=xz
|
|
|
|
|
|
2019-08-03 07:31:56 +03:00
|
|
|
CROSS_CCTOOLS_PATH=$MOZ_FETCHES_DIR/cctools
|
|
|
|
|
CROSS_SYSROOT=$MOZ_FETCHES_DIR/MacOSX10.11.sdk
|
2017-07-26 01:33:44 +03:00
|
|
|
|
2019-08-03 07:31:56 +03:00
|
|
|
export CC=$MOZ_FETCHES_DIR/clang/bin/clang
|
|
|
|
|
export CXX=$MOZ_FETCHES_DIR/clang/bin/clang++
|
|
|
|
|
export AR=$MOZ_FETCHES_DIR/clang/bin/llvm-ar
|
Bug 1551690 - be more specific about the LLVM target on OS X; r=nalexander
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
2019-05-21 20:53:44 +03:00
|
|
|
export CFLAGS="-target x86_64-apple-darwin -mlinker-version=137 -B ${CROSS_CCTOOLS_PATH}/bin -isysroot ${CROSS_SYSROOT} -I${CROSS_SYSROOT}/usr/include -iframework ${CROSS_SYSROOT}/System/Library/Frameworks"
|
2017-07-26 01:33:44 +03:00
|
|
|
export CXXFLAGS="-stdlib=libc++ ${CFLAGS}"
|
|
|
|
|
export LDFLAGS="${CXXFLAGS} -Wl,-syslibroot,${CROSS_SYSROOT} -Wl,-dead_strip"
|
|
|
|
|
|
|
|
|
|
# We patch tools/gn/bootstrap/bootstrap.py to detect this.
|
|
|
|
|
export MAC_CROSS=1
|
|
|
|
|
|
|
|
|
|
# Gn build scripts use #!/usr/bin/env python, which will be python 2.6 on
|
|
|
|
|
# the worker and cause failures. Work around this by putting python2.7
|
|
|
|
|
# ahead of it in PATH.
|
|
|
|
|
mkdir -p $WORKSPACE/python_bin
|
|
|
|
|
ln -s /usr/bin/python2.7 $WORKSPACE/python_bin/python
|
|
|
|
|
export PATH=$WORKSPACE/python_bin:$PATH
|
|
|
|
|
|
2019-08-01 12:55:26 +03:00
|
|
|
cd $GECKO_PATH
|
2017-07-26 01:33:44 +03:00
|
|
|
|
|
|
|
|
. taskcluster/scripts/misc/tooltool-download.sh
|
|
|
|
|
|
|
|
|
|
# The ninja templates used to bootstrap gn have hard-coded references to
|
|
|
|
|
# 'libtool', make sure we find the right one.
|
Bug 1551690 - be more specific about the LLVM target on OS X; r=nalexander
Our current OS X builds use `--target=x86_64-darwin11` (which
corresponds to OS X 10.7). This target is problematic for two reasons:
* We're actually targeting for OS X 10.9 (`MACOSX_DEPLOYMENT_TARGET`);
* It's slightly different from the default Rust target.
Let's address these problems in reverse order: differences from the Rust
target are bad, because the `--target` we provide to `clang` and the
Rust target find their way into LLVM bitcode files and the linker will
refuse to link together bitcode files that have incompatible targets.
Why are the two incompatible? The current `--target` doesn't have a
"vendor" in triple-speak, whereas the Rust one has "apple" as the
vendor (`x86_64-apple-darwin`) We therefore need to change the
`--target` we pass to `clang` to have a vendor of "apple".
This need is behind the {init,toolchain}.configure changes,
but it has ramifications elsewhere, because `clang` looks for
`--target`-prefixed build tools. So we have to change the `--target`
for cctools to get the right tool prefixes and we have to change the
`--target` for building clang ourselves so that *those* builds can find
the newly renamed cctools.
Once we've done, that's really enough; we don't *need to address the
first problem: While the `--target` might be `x86_64-apple-darwin11`,
both `clang` and `rustc` will dynamically choose the target triple that
eventually lands in LLVM bitcode files based on
`MACOSX_DEPLOYMENT_TARGET`, which we set in all builds. But the current
target is slightly misleading, and the cctools don't need to be prefixed
with a particular Darwin version, since they work for all Darwin
targets. Let's just drop the "11" from the `--target` and eliminate a
little bit of confusion.
Differential Revision: https://phabricator.services.mozilla.com/D31128
--HG--
extra : moz-landing-system : lando
2019-05-21 20:53:44 +03:00
|
|
|
ln -s $CROSS_CCTOOLS_PATH/bin/x86_64-apple-darwin-libtool $CROSS_CCTOOLS_PATH/bin/libtool
|
2017-07-26 01:33:44 +03:00
|
|
|
export PATH=$CROSS_CCTOOLS_PATH/bin:$PATH
|
|
|
|
|
|
|
|
|
|
. taskcluster/scripts/misc/build-gn-common.sh
|
