The ld that we use for Mac builds is old (Xcode circa OS X 10.7), and
also crashes in various ways when we try to use newer Rust versions
and/or pass options to make the linker work with newer Rust versions.
To mitigate this, let's build with a newer linker, compiled from:
https://github.com/tpoechtrager/cctools-port
We use this port, rather than the packages from opensource.apple.com,
because the packages from Apple have decidely non-intuitive build
systems, and require some hacking to get to build. This port, in
contrast, is simply built with:
CFLAGS='-mcpu=generic -mtune=generic' ./configure --target=x86_64-apple-darwin11
env MACOSX_DEPLOYMENT_TARGET=10.7 make
and the resulting x86_64-apple-darwin11-ld is renamed as 'ld' and
packaged up for automation's purposes.
However, since this linker is newer, it also produces bits of Mach-O
that our older build tools don't understand. Fortunately, we can pass
appropriate options to the linker to turn off generation of those Mach-O
bits.
The ld that we use for Mac builds is old (Xcode circa OS X 10.7), and
also crashes in various ways when we try to use newer Rust versions
and/or pass options to make the linker work with newer Rust versions.
To mitigate this, let's build with a newer linker, compiled from:
https://github.com/tpoechtrager/cctools-port
We use this port, rather than the packages from opensource.apple.com,
because the packages from Apple have decidely non-intuitive build
systems, and require some hacking to get to build. This port, in
contrast, is simply built with:
CFLAGS='-mcpu=generic -mtune=generic' ./configure --target=x86_64-apple-darwin11
env MACOSX_DEPLOYMENT_TARGET=10.7 make
and the resulting x86_64-apple-darwin11-ld is renamed as 'ld' and
packaged up for automation's purposes.
However, since this linker is newer, it also produces bits of Mach-O
that our older build tools don't understand. Fortunately, we can pass
appropriate options to the linker to turn off generation of those Mach-O
bits.
At this point, the only remaining part of the postflight for OSX
universal builds dates back to bug 834228. Since then, many things have
changed, one of them being that automation build steps have dependencies
that can be expressed through make dependencies.
While this is not directly related to bug 1244446, fixing this bug gets
more complicated if postflight needs to happen before some of the
automation build steps.
At this point, the only remaining part of the postflight for OSX
universal builds dates back to bug 834228. Since then, many things have
changed, one of them being that automation build steps have dependencies
that can be expressed through make dependencies.
While this is not directly related to bug 1244446, fixing this bug gets
more complicated if postflight needs to happen before some of the
automation build steps.
Gonk, Android, and the generic cross-compilation setup all were using a
different yet similar way to prefix the toolchain. The latter was even
wrong, since the target and target alias usually don't match actual
toolchain prefixes (which don't include the machine part of the target).
Now that we have cross-compilation tooltool packages for OS X, we can
use the common mozconfig to enable Rust on all OS X builds, regardless
of host OS.
Update tooltool manifest for macosx with a custom build of rustc 1.4.0
with --enable-rpath --disable-elf-tls and MACOSX_DEPLOYMENT_TARGET=10.7
on MacOS X 10.10.5, Xcode 7.1.1 (clang-700.1.76).
Built for x86_64-apple-darwin with the rustlib from a separate
i686-apple-darwin build copied into the tree to support 32-bit cross
for universal builds.
Since we've enabled rpath, we can drop the DYLD_LIBRARY_PATH setting
from mozconfig.rust. This method seems cleaner since the add/append
decision for DYLD_LIBRARY_PATH is verbose in shell.
Add a mozconfig fragment enabling rust on mac builds.
Include it in the official integration mozconfig files only.
Developer checkouts don't require rust.
This simplifies the medie PlatformDecoderModule build, and makes
it easier to create a toolchain needed for release builds. We
expect binaries built against the 10.7 sdk to still run on 10.6.
