Get rid of build-powerpc64le-toolchain.sh

[Gelbpunkt]

The dist-powerpc64le-linux-musl runner never actually used the toolchain that the script produced, it instead used the one from crosstool-ng.

The dist-powerpc64le-linux-gnu runner did use it, from what I can tell mainly to get a glibc 2.17 version with ppc64le support backported. Since crosstool-ng has the necessary patches, we can just use crosstool-ng to get an appropriate toolchain. While at it, use kernel 3.10 headers since that's the version documented in platform support for this target.

try-job: dist-powerpc64le-linux-gnu
try-job: dist-powerpc64le-linux-musl

[rustbot]

r? @marcoieni

rustbot has assigned @marcoieni.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[jieyouxu]

@bors2 try

[rust-bors]

⌛ Trying commit 12bc409 with merge 3956ef4…

To cancel the try build, run the command @bors2 try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 3956ef4 (3956ef4a164e4d59f20f15356a748e6d9adb6af6, parent: c96a69059ecc618b519da385a6ccd03155aa0237)

[marcoieni]

Hi, thanks for this PR! It looks like a great cleanup. I'll ask for some help to review it.

The dist-powerpc64le-linux-musl runner never actually used the toolchain that the script produced, it instead used the one from crosstool-ng.

Did you get this from the script? If yes, where?

from what I can tell mainly to get a glibc 2.17 version

How can I double check this?

[Gelbpunkt]

Did you get this from the script? If yes, where?

The PATH variable points to the crosstool-ng output. I also confirmed it manually by entering the build container and running powerpc64le-unknown-linux-musl-gcc --version and it includes "crosstool-ng". Also, the script's GCC targets glibc, not musl.

How can I double check this?

Not sure what your question is, I got this from reading the script. Glibc 2.17 is the documented baseline of the target.

[cuviper]

FWIW, I use a pipeline like this to check the resulting symbol versions:

$ readelf -V librustc_driver-*.so | grep -o 'Name: \S*' | sort -uV
Name: GCC_3.0
Name: GCC_3.3
Name: GCC_3.4.4
Name: GCC_4.2.0
Name: GLIBC_2.17

(and repeat for all binaries, though librustc_driver is big enough that it usually represents everything)

In the CI artifacts from your try build, everything looks good to me except for one:

./rustc/lib/rustlib/powerpc64le-unknown-linux-gnu/bin/rust-objcopy
Name: GCC_3.0
Name: GCC_3.3
Name: GCC_3.4
Name: GCC_4.2.0
Name: GLIBC_2.2.5
Name: GLIBC_2.3
Name: GLIBC_2.3.4
Name: GLIBC_2.4
Name: GLIBC_2.6
Name: GLIBC_2.14
Name: GLIBC_2.15
Name: GLIBC_2.16
Name: GLIBC_2.17
Name: GLIBC_2.32
Name: GLIBC_2.33
Name: GLIBC_2.34

... but that appears to be from the x86-64 build host, not for PPC! (probably not a new problem)

$ file ./rustc/lib/rustlib/powerpc64le-unknown-linux-gnu/bin/rust-objcopy
./rustc/lib/rustlib/powerpc64le-unknown-linux-gnu/bin/rust-objcopy: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6507171c1208cad17b064ffbff3b348c18680367, for GNU/Linux 3.2.0, not stripped

[Gelbpunkt]

... but that appears to be from the x86-64 build host, not for PPC! (probably not a new problem)

Yep! Can confirm this on a powerpc64le-unknown-linux-gnu host that installed the toolchain via rustup:

adrian@theta:~$ find ~/.rustup/ -name *objcopy*
/home/adrian/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/powerpc64le-unknown-linux-gnu/bin/rust-objcopy
adrian@theta:~$ file /home/adrian/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/powerpc64le-unknown-linux-gnu/bin/rust-objcopy
/home/adrian/.rustup/toolchains/nightly-powerpc64le-unknown-linux-gnu/lib/rustlib/powerpc64le-unknown-linux-gnu/bin/rust-objcopy: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6507171c1208cad17b064ffbff3b348c18680367, for GNU/Linux 3.2.0, not stripped

This happens on all cross builds, actually. E.g. aarch64-unknown-linux-musl has the same issue.