| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
|
|
|
|
|
|
The current cross-compilation toolchain for the LoongArch64 target
consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils
2.40 has known issues that in broken binaries without any error reports:
- https://github.com/rust-lang/rust/issues/121289
- https://github.com/cross-rs/cross/issues/1538
This patch upgrades the cross-compilation toolchain for the LoongArch64 target
to resolve these issues.
- GCC: 13.2.0 -> 14.2.0
- Binutils: 2.40 -> 2.42
The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36
distribution, and no issues have been identified.
|
|
|
|
I'm proposing this GCC upgrade since it addresses bug #125619. The
regression in question affects stable release consumers who tend to have
no exposure to Rust build tools, so if at all possible, I would like to
have it resolved in the next stable release. I have tried to fix the bug
in `compiler-builtins`, which led to submitting a PR for `compiler-rt`
in upstream LLVM, but it may take a long time before these upstreams
address this regression.
A summary of why upgrading GCC solves the regression follows.
`__multc3()` is a builtin function `compiler-builtins` exposes for
specifically aarch64, non-Windows targets [1]. The object file for it is
included in `staticlib` archives through `libstd`. The implementation
for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`.
Upstream `compiler-rt` normally builds the C file using the Clang
from the same LLVM version. On the other hand, `compiler-builtins`
builds the C file using GCC, outside of the usual LLVM build system.
The upstream implementation doesn't have feature detection which
works for GCC version older than 10, and ends up producing an
unlinkable object.
Upstream LLVM might be slow to respond to this issue as they might deem
`compiler-builtin` as doing something out of the ordinary from their
perspective. They might reasonably assume everyone builds `compiler-rt`
through LLVM's build system.
I have done the following to test this change:
- verified that a local build without this patch exhibits the
regression.
- verified that with this patch, the object for `__multc3()` has no
reference to undefined functions in the symbol table.
- verified that with this patch, `rustc` is usable to build Ruby with
YJIT, and that the reported regression is resolved.
[1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539
|
|
|
|
|
|
Currently, having a dirty `obj/` directory is sufficient to abort CI
tests. This results in errors like the following:
```
...
== end clock drift check ==
sccache: Starting the server...
configure: error: Existing 'config.toml' detected.
== clock drift check ==
...
```
This is subtle and doesn't give a good idea as to what causes the issue.
With this patch, the error becomes more prominent and a resolution is
suggested:
```
== end clock drift check ==
sccache: Starting the server...
configure: ERROR: Existing 'config.toml' detected. Exiting
Is objdir '/home/tmgross/projects/rust/obj' clean?
== clock drift check ==
```
|
|
|
|
Co-Authored-By: YANG Xiaojuan <yangxiaojuan@loongson.cn>
|
|
|
|
|
|
* architecture
* configures
* preparation
* toolstate
* unknown
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
These have no change in compatibility, still Linux 4.4 and glibc 2.23.
|
|
Compressed debug is enabled by default for gas (assembly) on Linux/x86
targets, and we started building our own in #102530, but that made our
`compiler_builtins` incompatible with binutils < 2.32. Add an explicit
option to disable that in our crosstool-ng config. Fixes #102703.
|
|
The system GCC 5 in ubuntu:16.04 will be too old to compile LLVM 16, so
we need an upgrade. To avoid raising the minimum glibc requirements for
`i586-unknown-linux-gnu`, this target is converted to a crosstool-ng
toolchain, *relaxing* it to the same Linux 3.2 / glibc 2.17 minimum we
use elsewhere. The musl targets still use Ubuntu's system toolchain, but
this doesn't have the same compatibility concerns.
|
|
With binutils 2.32, we were getting errors like this:
relocation truncated to fit: R_PPC_PLTREL24 against symbol
`__cxa_atexit@@GLIBC_2.1.3' defined in .plt section in
/x-tools/powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu/sysroot/usr/lib/crt1.o
but it builds okay with binutils 2.30.
|
|
This is implementing the MCP from rust-lang/compiler-team#493. It is
increasing the minimum requirements of a couple Tier 1 targets, and
others at lower tiers, so this should go through FCP sign-offs for both
`T-compiler` and `T-release`.
The new `linux-gnu` baseline is kernel 3.2 and glibc 2.17. We will also
take that kernel as the minimum floor for _all_ `*-linux-*` targets, so
it may be broadly assumed in the implementation of the standard library.
That does not preclude specific targets from having greater requirements
where it makes sense, like a new arch needing something newer, or a
platform like `linux-android` choosing a newer baseline.
|
|
Update to Ubuntu 20.04 and crosstool-ng 1.24.0. I've updated the
ct-ng config and then manually reset the kernel and glibc versions
to the oldest supported.
Specifically, we're updating from kernel 2.6.32.68 to 2.6.32.71
and glibc 2.11.1 to 2.12.1 here. The compiler toolchain is also
updated, but I don't think that's relevant for compatibility.
|
|
|
|
|
|
|
|
|
|
We need to add runners designed for an aarch64 host system, and it'd be
nice to return an error message if someone tries to run an image
designed for an host architecture in another one.
To start the work on this, this commit moves all the existing builders
in the host-x86_64 directory, and changes the run.sh script to look up
the image in the correct directory based on the host architecture.
|
|
dist-arm-linux and dist-armhf-linux
|
|
I spent a while debugging a strage linker error about an outdated `glibc` version, only to discover that it was caused by a stale `obj` directory. It wasn't obviously to be that using the same obj dir with multiple Docker images (for the same target triple) could be a problem.
This commit adds a note to the README, which should hopefully be helpful to anyone else who runs into this issue.
|
|
This reverts commit 4f97e5d41160e256c9d76d26432831ece83ef480.
|
|
|
|
dist-armv7-linux
|
|
Now that we've fully moved to Azure Pipelines and bors has been updated
to only gate on Azure this commit removes the remaining Travis/AppVeyor
support contained in this repository. Most of the deletions here are
related to producing better output on Travis by folding certain
sections. This isn't supported by Azure so there's no need to keep it
around, and if Azure ever adds support we can always add it back!
|
|
|
|
|
|
|
|
|
|
|
|
With `-mcpu=power4`, code might use instructions like `fcfid`, excluding
older CPUs like the PowerPC G4, which apparently some users would like
to use. The generic `-mcpu=powerpc` should stick to pure 32-bit PowerPC
instructions.
Fixes rust-lang/cargo#3852.
|
|
Using Ubuntu's cross-toolchains for powerpc* and s390x meant they were
depending on glibc symbols from Ubuntu 16.04. And if that host is ever
updated to a new release, the toolchains would raise the bar too.
This switches powerpc, powerpc64, and s390x to use crosstool-ng
toolchains, configured approximately like RHEL6 with kernel 2.6.32 and
glibc 2.12. This ABI level should also be compatible with Debian 7
(wheezy) and Ubuntu 12.04 (precise).
For powerpc64le, the challenge was that only glibc-2.19 officially added
support, but RHEL7 backported those changes to glibc-2.17. The backport
patches are complex and numerous, so instead of trying to push those
into crosstool-ng, this just uses glibc binaries directly from CentOS 7
and builds the toolchain manually.
This is ported from rust-lang/rust-buildbot#149.
r? @alexcrichton
|
|
This commit updates the compilers for many of the artifacts that we're producing
on Travis. These compilers are all compiled by crosstool-ng as they're currently
done for the images in which we're building all our cross compiled compilers.
The purpose of this commit is that when we ship binaries the artifacts won't
require a newer glibc, but rather be as compatible as possible with Linux
distributions by working with a very old version of glibc.
This commit always allocates a new matrix entry for the i686/x86_64 builder.
This builder is dedicated to just producing artifacts and eventually we'll
expand it to building other tools like Cargo and the RLS. The other builders
testing i686 and x86_64 won't use these historical toolchains.
|
