Its use was removed from Firefox in bug 552864, in Thunderbird in bug 668869
and in Seamonkey in bug 722262. That was 10 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D147484
The llvm-symbolizer tasks currently extract a llvm-symbolizer from clang
tasks. Changes in clang 14 make the hack that we have in place to keep
llvm-symbolizer statically linked to libllvm while clang uses a dynamic
libllvm not work anymore, so it's time to bite the bullet and build
llvm-symbolizer separately.
We share most of the build setup with the compiler-rt build.
Differential Revision: https://phabricator.services.mozilla.com/D140711
Use the SHT_RELR format which significantly improves the size reduction
from elfhack:
total size of .rel.* + .elfhack.* sections
x86 x86_64 android-arm
plain 3532904 10739544 3488888
current-elfhack 1085815 1155994 1042048
relr-elfhack 130219 193552 113840
Differential Revision: https://phabricator.services.mozilla.com/D134756
Elfhack currently can't deal with files larger than 4GiB because it
translates all ELF data structures to the 32-bits variant, even for
64-bits ELF files. So if the original file has e.g. sections that start
after the 4GiB boundary, they can't be represented in memory.
Practically speaking, this is not causing problems, but has prevented a
working elfhack for aarch64 because e.g. some relocation types don't fit
in the 32-bits ELF representation.
Differential Revision: https://phabricator.services.mozilla.com/D134745
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
We leave the following ones unchanged:
- geckodriver because the results are used to releases on github.
- sixgill because the script that creates it is not in-tree.
- *-dist-toolchain because sccache is not expecting a .tar.zst.
We use native tar support in most cases, except for toolchain scripts also
used on Windows, for which we use our zstdpy script.
Differential Revision: https://phabricator.services.mozilla.com/D124733
librnp is used by Thunderbird for OpenPGP support. Until now, official builds
have been built statically linked to Clang/LLVM's libc++ to avoid problems with
libstdc++ symbols.
Recent build changes have narrowed the gap significantly, leaving out_of_range
and invalid_argument called with char const* rather than std::string.
Differential Revision: https://phabricator.services.mozilla.com/D123381
As this means stdc++compat also would need to be built when
cross-building for Windows on Linux, we also recurse in the stdc++compat
directory in that case. It was already possible to use
--enable-stdcxx-compat in that configuration, and that wasn't working
(there are other problems that prevent it from working, but we're going
to fix them shortly).
Differential Revision: https://phabricator.services.mozilla.com/D122195
Since the minimum required version of gcc and libstdc++ is 7.1 as of bug
1536848, the _GLIBCXX_RELEASE macro is available on all supported
versions. Which means instead of grabbing the largest version of the
libstdc++ symbols and tweaking for that, we can just tweak for
_GLIBCXX_RELEASE. We also remove the conditions that are always true due
to the versions involved.
Differential Revision: https://phabricator.services.mozilla.com/D122194
A lot of work happens on the wayland backend, and it regularly breaks tier-3
systems where wayland is not supported. Setting up X11-only builds will help
catch those breakages earlier.
Differential Revision: https://phabricator.services.mozilla.com/D121691
This allows to use the same toolchain docker images as other toolchains,
based on Debian buster.
While here, use the default max-run-time, which is more than enough for
this toolchain.
Differential Revision: https://phabricator.services.mozilla.com/D119137
Because GCC is built in stages, the final stage is built with
intermediate stages's GCC, which handles the sysroot correctly, so we
end up with headers and libraries with the expected compatibility.
This allows to use the same toolchain docker images as other toolchains,
based on Debian buster.
Differential Revision: https://phabricator.services.mozilla.com/D119136
Bug 1634204 bumped the maximum version of symbols allowed in our
dependency upon libstdc++, which effectively makes some of the
stdc++compat code dead. We can now remove it.
Differential Revision: https://phabricator.services.mozilla.com/D104617
When using the --sysroot argument to clang, clang changes where it
searches for libraries in its own directory, and excludes the lib and
lib32 subdirectories. So we need to move the gcc files to a place where
it does look (and that it also looks without --sysroot).
We however still keep a copy of libstdc++ in the lib directory for
runtime purposes.
Differential Revision: https://phabricator.services.mozilla.com/D104123
