- The rustc book
- Tier 1 with Host Tools
- Tier 1
- Tier 2 with Host Tools
- Tier 2
- Tier 3
- configure: error: The powerpc64le is not supported. #1227
- Comments
- edowson commented Sep 2, 2019
- edowson commented Sep 2, 2019
- edowson commented Sep 2, 2019
- cpackham commented Sep 4, 2019 •
- cpackham commented Sep 4, 2019 •
- cpackham commented Sep 4, 2019 •
- cpackham commented Sep 4, 2019
- edowson commented Sep 4, 2019 •
- cpackham commented Sep 4, 2019
- cpackham commented Sep 4, 2019
- cpackham commented Sep 5, 2019 •
- edowson commented Sep 6, 2019 •
- cpackham commented Sep 7, 2019
- edowson commented Sep 8, 2019
- edowson commented Sep 9, 2019
- qhaas commented Mar 24, 2020
The rustc book
Support for different platforms («targets») are organized into three tiers, each with a different set of guarantees. For more information on the policies for targets at each tier, see the Target Tier Policy.
Targets are identified by their «target triple» which is the string to inform the compiler what kind of output should be produced.
Tier 1 with Host Tools
Tier 1 targets can be thought of as «guaranteed to work». The Rust project builds official binary releases for each tier 1 target, and automated testing ensures that each tier 1 target builds and passes tests after each change.
Tier 1 targets with host tools additionally support running tools like rustc and cargo natively on the target, and automated testing ensures that tests pass for the host tools as well. This allows the target to be used as a development platform, not just a compilation target. For the full requirements, see Tier 1 with Host Tools in the Target Tier Policy.
All tier 1 targets with host tools support the full standard library.
| target | notes |
|---|---|
| aarch64-unknown-linux-gnu | ARM64 Linux (kernel 4.2, glibc 2.17+) 1 |
| i686-pc-windows-gnu | 32-bit MinGW (Windows 7+) |
| i686-pc-windows-msvc | 32-bit MSVC (Windows 7+) |
| i686-unknown-linux-gnu | 32-bit Linux (kernel 2.6.32+, glibc 2.11+) |
| x86_64-apple-darwin | 64-bit macOS (10.7+, Lion+) |
| x86_64-pc-windows-gnu | 64-bit MinGW (Windows 7+) |
| x86_64-pc-windows-msvc | 64-bit MSVC (Windows 7+) |
| x86_64-unknown-linux-gnu | 64-bit Linux (kernel 2.6.32+, glibc 2.11+) |
Stack probes support is missing on aarch64-unknown-linux-gnu , but it’s planned to be implemented in the near future. The implementation is tracked on issue #77071.
Tier 1
Tier 1 targets can be thought of as «guaranteed to work». The Rust project builds official binary releases for each tier 1 target, and automated testing ensures that each tier 1 target builds and passes tests after each change. For the full requirements, see Tier 1 target policy in the Target Tier Policy.
At this time, all Tier 1 targets are Tier 1 with Host Tools.
Tier 2 with Host Tools
Tier 2 targets can be thought of as «guaranteed to build». The Rust project builds official binary releases for each tier 2 target, and automated builds ensure that each tier 2 target builds after each change. Automated tests are not always run so it’s not guaranteed to produce a working build, but tier 2 targets often work to quite a good degree and patches are always welcome!
Tier 2 targets with host tools additionally support running tools like rustc and cargo natively on the target, and automated builds ensure that the host tools build as well. This allows the target to be used as a development platform, not just a compilation target. For the full requirements, see Tier 2 with Host Tools in the Target Tier Policy.
All tier 2 targets with host tools support the full standard library.
NOTE: Tier 2 targets currently do not build the rust-docs component.
| target | notes |
|---|---|
| aarch64-apple-darwin | ARM64 macOS (11.0+, Big Sur+) |
| aarch64-pc-windows-msvc | ARM64 Windows MSVC |
| aarch64-unknown-linux-musl | ARM64 Linux with MUSL |
| arm-unknown-linux-gnueabi | ARMv6 Linux (kernel 3.2, glibc 2.17) |
| arm-unknown-linux-gnueabihf | ARMv6 Linux, hardfloat (kernel 3.2, glibc 2.17) |
| armv7-unknown-linux-gnueabihf | ARMv7 Linux, hardfloat (kernel 3.2, glibc 2.17) |
| mips-unknown-linux-gnu | MIPS Linux (kernel 4.4, glibc 2.23) |
| mips64-unknown-linux-gnuabi64 | MIPS64 Linux, n64 ABI (kernel 4.4, glibc 2.23) |
| mips64el-unknown-linux-gnuabi64 | MIPS64 (LE) Linux, n64 ABI (kernel 4.4, glibc 2.23) |
| mipsel-unknown-linux-gnu | MIPS (LE) Linux (kernel 4.4, glibc 2.23) |
| powerpc-unknown-linux-gnu | PowerPC Linux (kernel 2.6.32, glibc 2.11) |
| powerpc64-unknown-linux-gnu | PPC64 Linux (kernel 2.6.32, glibc 2.11) |
| powerpc64le-unknown-linux-gnu | PPC64LE Linux (kernel 3.10, glibc 2.17) |
| riscv64gc-unknown-linux-gnu | RISC-V Linux (kernel 4.20, glibc 2.29) |
| s390x-unknown-linux-gnu | S390x Linux (kernel 2.6.32, glibc 2.11) |
| x86_64-unknown-freebsd | 64-bit FreeBSD |
| x86_64-unknown-illumos | illumos |
| x86_64-unknown-linux-musl | 64-bit Linux with MUSL |
| x86_64-unknown-netbsd | NetBSD/amd64 |
Tier 2
Tier 2 targets can be thought of as «guaranteed to build». The Rust project builds official binary releases for each tier 2 target, and automated builds ensure that each tier 2 target builds after each change. Automated tests are not always run so it’s not guaranteed to produce a working build, but tier 2 targets often work to quite a good degree and patches are always welcome! For the full requirements, see Tier 2 target policy in the Target Tier Policy.
The std column in the table below has the following meanings:
- вњ“ indicates the full standard library is available.
- * indicates the target only supports no_std development.
NOTE: Tier 2 targets currently do not build the rust-docs component.
| target | std | notes |
|---|---|---|
| aarch64-apple-ios | вњ“ | ARM64 iOS |
| aarch64-apple-ios-sim | вњ“ | Apple iOS Simulator on ARM64 |
| aarch64-fuchsia | вњ“ | ARM64 Fuchsia |
| aarch64-linux-android | вњ“ | ARM64 Android |
| aarch64-unknown-none-softfloat | * | Bare ARM64, softfloat |
| aarch64-unknown-none | * | Bare ARM64, hardfloat |
| arm-linux-androideabi | вњ“ | ARMv7 Android |
| arm-unknown-linux-musleabi | вњ“ | ARMv6 Linux with MUSL |
| arm-unknown-linux-musleabihf | вњ“ | ARMv6 Linux with MUSL, hardfloat |
| armebv7r-none-eabi | * | Bare ARMv7-R, Big Endian |
| armebv7r-none-eabihf | * | Bare ARMv7-R, Big Endian, hardfloat |
| armv5te-unknown-linux-gnueabi | вњ“ | ARMv5TE Linux (kernel 4.4, glibc 2.23) |
| armv5te-unknown-linux-musleabi | вњ“ | ARMv5TE Linux with MUSL |
| armv7-linux-androideabi | вњ“ | ARMv7a Android |
| armv7-unknown-linux-gnueabi | вњ“ | ARMv7 Linux (kernel 4.15, glibc 2.27) |
| armv7-unknown-linux-musleabi | вњ“ | ARMv7 Linux with MUSL |
| armv7-unknown-linux-musleabihf | вњ“ | ARMv7 Linux with MUSL, hardfloat |
| armv7a-none-eabi | * | Bare ARMv7-A |
| armv7r-none-eabi | * | Bare ARMv7-R |
| armv7r-none-eabihf | * | Bare ARMv7-R, hardfloat |
| asmjs-unknown-emscripten | вњ“ | asm.js via Emscripten |
| i586-pc-windows-msvc | вњ“ | 32-bit Windows w/o SSE |
| i586-unknown-linux-gnu | вњ“ | 32-bit Linux w/o SSE (kernel 4.4, glibc 2.23) |
| i586-unknown-linux-musl | вњ“ | 32-bit Linux w/o SSE, MUSL |
| i686-linux-android | вњ“ | 32-bit x86 Android |
| i686-unknown-freebsd | вњ“ | 32-bit FreeBSD |
| i686-unknown-linux-musl | вњ“ | 32-bit Linux with MUSL |
| mips-unknown-linux-musl | вњ“ | MIPS Linux with MUSL |
| mips64-unknown-linux-muslabi64 | вњ“ | MIPS64 Linux, n64 ABI, MUSL |
| mips64el-unknown-linux-muslabi64 | вњ“ | MIPS64 (LE) Linux, n64 ABI, MUSL |
| mipsel-unknown-linux-musl | вњ“ | MIPS (LE) Linux with MUSL |
| nvptx64-nvidia-cuda | * | —emit=asm generates PTX code that runs on NVIDIA GPUs |
| riscv32i-unknown-none-elf | * | Bare RISC-V (RV32I ISA) |
| riscv32imac-unknown-none-elf | * | Bare RISC-V (RV32IMAC ISA) |
| riscv32imc-unknown-none-elf | * | Bare RISC-V (RV32IMC ISA) |
| riscv64gc-unknown-none-elf | * | Bare RISC-V (RV64IMAFDC ISA) |
| riscv64imac-unknown-none-elf | * | Bare RISC-V (RV64IMAC ISA) |
| sparc64-unknown-linux-gnu | вњ“ | SPARC Linux (kernel 4.4, glibc 2.23) |
| sparcv9-sun-solaris | вњ“ | SPARC Solaris 10/11, illumos |
| thumbv6m-none-eabi | * | Bare Cortex-M0, M0+, M1 |
| thumbv7em-none-eabi | * | Bare Cortex-M4, M7 |
| thumbv7em-none-eabihf | * | Bare Cortex-M4F, M7F, FPU, hardfloat |
| thumbv7m-none-eabi | * | Bare Cortex-M3 |
| thumbv7neon-linux-androideabi | вњ“ | Thumb2-mode ARMv7a Android with NEON |
| thumbv7neon-unknown-linux-gnueabihf | вњ“ | Thumb2-mode ARMv7a Linux with NEON (kernel 4.4, glibc 2.23) |
| thumbv8m.base-none-eabi | * | ARMv8-M Baseline |
| thumbv8m.main-none-eabi | * | ARMv8-M Mainline |
| thumbv8m.main-none-eabihf | * | ARMv8-M Mainline, hardfloat |
| wasm32-unknown-emscripten | вњ“ | WebAssembly via Emscripten |
| wasm32-unknown-unknown | вњ“ | WebAssembly |
| wasm32-wasi | вњ“ | WebAssembly with WASI |
| x86_64-apple-ios | вњ“ | 64-bit x86 iOS |
| x86_64-fortanix-unknown-sgx | вњ“ | Fortanix ABI for 64-bit Intel SGX |
| x86_64-fuchsia | вњ“ | 64-bit Fuchsia |
| x86_64-linux-android | вњ“ | 64-bit x86 Android |
| x86_64-pc-solaris | вњ“ | 64-bit Solaris 10/11, illumos |
| x86_64-unknown-linux-gnux32 | вњ“ | 64-bit Linux (x32 ABI) (kernel 4.15, glibc 2.27) |
| x86_64-unknown-redox | вњ“ | Redox OS |
Tier 3
Tier 3 targets are those which the Rust codebase has support for, but which the Rust project does not build or test automatically, so they may or may not work. Official builds are not available. For the full requirements, see Tier 3 target policy in the Target Tier Policy.
The std column in the table below has the following meanings:
- вњ“ indicates the full standard library is available.
- * indicates the target only supports no_std development.
- ? indicates the standard library support is unknown or a work-in-progress.
The host column indicates whether the codebase includes support for building host tools.
Источник
configure: error: The powerpc64le is not supported. #1227
Comments
edowson commented Sep 2, 2019
I’m tried using crosstool-ng to build a toolchain for an IBM Power9 system on an Ubuntu-18.04 x86_64 host. The target triple that I want is ppc64le-unknown-linux-gnu.
When I try to build the toolchain, I get the following error:
crosstool-NG version
crosstool-NG version 1.24.0.6-afaf7b9
Host OS and its version
Ubuntu-18.04, x86_64 linux
The text was updated successfully, but these errors were encountered:
edowson commented Sep 2, 2019
I tried building once again, using the existing powerpc64le sample, but still get a build error:
The build.log file for this particular build is too large (34MB) to attach here, but it is the default config, so it can be reproduced.
edowson commented Sep 2, 2019
I just tried building powerpc64le-unknown-linux-gnu directly on an IBM Power9 system, and I get the following build error:
The last few lines leading up to the error in the build.log file are as follows:
cpackham commented Sep 4, 2019 •
The first error seems to be due to an old libc (CT_GLIBC_V_2_17=y) being selected which doesn’t seem to like powerpc64le (I’m not going to dig into that one any further).
The other errors it’s hard to tell because you haven’t attached a build.log from any of them.
I’m attempting to reproduce your issue with the powerpc64le-unknown-linux-gnu sample. I’ll report back on that.
cpackham commented Sep 4, 2019 •
So the powerpc64le-unknown-linux-gnu sample worked for me in the following environment
One thing about this environment is there is no python3 (or python) so glibc-2.29 is excluded automatically
cpackham commented Sep 4, 2019 •
Right adding python3 to my environment and thus enabling glibc-2.29 I can reproduce the problem. Here’s the snippet from build.log.gz
I’m tempted to say this is a regression in glibc but maybe there’s some new option crosstool-ng needs to be passing. @edowson as a workaround is downgrading to glibc 2.28 and option for you?
cpackham commented Sep 4, 2019
looks like some how both the rs6000 and soft floating point support has been enabled.
edowson commented Sep 4, 2019 •
@cpackham I’m okay with downgrading to glibc-2.28.
On the x86_64 system, ldd shows that I have glibc-2.27 installed. So, any version of glibc-2.27 or higher would be fine.
Would you be able to fix the issue with rs6000 and soft-floating point support being enabled? That was a good catch.
cpackham commented Sep 4, 2019
cpackham commented Sep 4, 2019
Looks like glibc-2.30 doesn’t have this issue. Just skimming the changes in the glibc git repo I can’t spot anything obvious that addresses the issue. I have got a PR #1232 that adds the new glibc version you could take that for a spin.
cpackham commented Sep 5, 2019 •
I think I know what the problem is see here
The ARC patch ends up setting with_fp_cond for non-arc systems. Which turns off floating point support (which is supposed to be mandatory for powerpc64). Deleting packages/glibc/2.29/0001-Add-ARC-architecture.patch would fix the build issue for you. There may be a less drastic fix (i.e. modify the patch).
edowson commented Sep 6, 2019 •
@cpackham I managed to get the toolchain built on a Power9 system. I’ve installed the built toolchain into a separate folder. Why do I get a GLIBC_2.29 not found error, when I try to run ./clang —version from my custom sysroot location?
libm.so.6 was manually moved to /lib64/libm.so.6 in order to assemble a cross-compiler toolchain.
I have set export LD_LIBRARY_PATH=/project/software/library/unrealengine-4.24-ppc64le-master/Engine/Extras/ThirdPartyNotUE/SDKs/HostLinux/Linux_ppc64le/v14_clang-7.0.1-centos7/powerpc64le-unknown-linux-gnu/lib64
but it still gives me the same error.
How does glibc get resolved on a host system?
cpackham commented Sep 7, 2019
@edowson I’m not sure how clang is going to work with a glibc compiled for gcc. I guess it might work if you can tell it the right sysroot (e.g —sysroot=/path/to/sysroot) although I’m used to the compiler being tightly coupled to the libc.
Are you able to just use the generated gcc instead of clang? (based on the paths I’m guessing you need clang for some kind of custom language front-end).
Another option that I have used for Rust is to convince llvm (i.e. clang) to output assembly and use the gcc assembler/linker.
edowson commented Sep 8, 2019
@cpackham I rebuilt the powerpc64le toolchain using glibc-2.27 instead of the default glibc-2.29 , and it picks up the system installed glibc-2.27 .
edowson commented Sep 9, 2019
@cpackham I think if I set LD_LIBRARY_PATH as follows, it might resolve the issue:
qhaas commented Mar 24, 2020
The first error seems to be due to an old libc (CT_GLIBC_V_2_17=y) being selected which doesn’t seem to like powerpc64le (I’m not going to dig into that one any further).
GLIBC 2.17 on ppc64le occupies an extant niche due to supercomputers like Sierra and Summit running ppc64le Red Hat Enterprise Linux 7 (RHEL7).
I adjusted the default ‘powerpc64le-unknown-linux-gnu’ config target to use the same major/minor version of the kernel (4.14), glibc (2.17), and binutils (2.27) of ppc64le RHEL7 and encountered this same error during the building of the toolchain ‘error: The powerpc64le is not supported’.
It appeared in both latest stable (b2151f1, crosstool-ng-1.24.0) and master (be1b566) on a power9 system in RHEL7.
In another discussion, they mention that upstream ppc64le landed in glibc 2.19, so RH must have backported ppc64le support in their branch of glibc 2.17, unfortunately, I don’t see it being easy to apply all of what they’ve done to the flavor used by crosstool-ng.
For those lacking a ppc64le system and wanting to give it a shot, one can use the attached dockerfile on x86-64 systems by leveraging qemu. In x86-64 Ubuntu 18.04, deploy packages qemu-user qemu-user-static binutils-powerpc64le-linux-gnu .
Источник
