The return-empty-string-non-mangled.patch apparently landed in r249437
upstream, so we don't need to carry around our own version. The patch
is still nominally used for building clang on Mac, so I have not removed
it from version control.
Instead of relying on the assumption that a previous run of CMake was
using the same arguments, remove the CMake cache file and re-run it.
This way the script is robust no matter what kind of build directory
existed from before.
Since individual config files have different source repos declared,
it's better to deal with each individual source directory separately.
Also make sure to revert any of the existing changes in each directory
so that attempts to apply patches to the source directory or import
our static analysis checks into clang-tidy are guaranteed to always
succeed.
This revision fixes a clang devirtualization bug and also includes
support for -fbuiltin-module-map, which is useful in making ffmpeg
compile correctly.
clang-cl would normally derive its MSVC emulation bits from the
installed MSVC version, but we don't have an installed MSVC in this
scenario, so we have to use command-line options instead. We use
similar options for Gecko builds.
In a taskcluster world, we cannot used fixed directories, since we don't
know the absolute path of the directory we're building in ahead of time.
(We could pass it in to the build script, or discover it in the script
itself, but that wouldn't really solve the next problem.) This change
does make the builds not reproducible, but as we're using clang-cl
purely for secondary purposes on Windows, rather than for shipping
Firefox binaries (as we would on Mac, say), I don't feel bad about
punting the reproducibility issue down the road a bit.
We cannot depend on a fixed location for cl.exe in a taskcluster world.
We therefore need to make our build-clang.py script accomodate relative
path names for cc/cxx and assume those are binaries that should be
looked up on PATH.
We also need to modify the Linux build script so that the virtualenv is
used to look up the new 'which' package.
We need to rebuild clang with libc++ to get compatible headers for cross
builds. libc++abi is a dependency of libc++, as the build instructions
says [0].
[0] http://libcxx.llvm.org/docs/BuildingLibcxx.html
Ideally, we'd use the tarballs from
http://llvm.org/releases/download.html but I didn't feel like modifying
the script more than I already did to make it work at all (bug 1262735).
The new tarball for Linux was built on
https://tools.taskcluster.net/task-inspector/#LCUn8aEgTBeRJ11a3qTlDQ/0
The new tarball for Mac was built on a loaner, after installing cmake
and ninja, as well as building ld64 127.2 from source because the
installed version would assert while building clang. The latter required
manually adding some missing headers to /usr/include. TSAN was also
disabled because it requires APIs that are not available on the OSX
version on the build slaves (e.g. pthread_introspection_hook_install).
Building clang also required using a mac clang from tooltool, the system
one lacking support for atomics.
Both point to the same path for cc and cxx, but not for gcc_dir, which
makes no sense. That's the only significant difference between both, so
just merge them both, and use the merged file in the taskcluster build
script.
Instead, copy libgcc from the GCC used to build clang at each stage.
When passing --gcc-toolchain, the flag ends up appearing in the output
of llvm-config, and completely defeats the purpose of copying libgcc in
clang/lib/gcc.
Since build-clang.py requires a gcc_dir to be set, and we're using GCC
from there to build clang, we might as well copy libgcc from there
instead of building a fresh GCC. On the taskcluster job building clang,
GCC comes from a tooltool package that is already the result of
build-gcc anyways.
When passing -DCMAKE_C_COMPILER="gcc -flags" to CMake, ninja then tries
to literally call "gcc -flags", not "gcc" "-flags", and a "gcc -flags"
file obviously doesn't exist, so the build fails.
This fixes a regression from bug 1042132. Hopefully, this also doesn't
regress bug 1042132 itself.
Ehsan Akhgari
Iris Hsiao
Nathan Froyd
Wes Kocher
Phil Ringnalda
Ryan VanderMeulen
Ting-Yu Chou
Wander Lairson Costa
Mike Hommey