Upgrade armv7-unknown-linux-gnueabihf to glibc 2.19.

[briansmith]

With this change, ring 0.14 builds
successfully with cross test --target=armv7-unknown-linux-gnueabihf.
Without this change the same command fails because the older glibc doesn't
expose getauxval.

Signed-off-by: Brian Smith [email protected]

[briansmith]

Note that ring only requires getauxval on ARM and Aarch64 targets, not on any others, so this is the only target that needs to be upgraded in this manner, so the scope of the glibc bump is isolated to just this target.

[jamesmunns]

Hey @briansmith, typically cross tends to avoid updating glibc for maximum compatibility. Would you consider adding this as a separate target, perhaps with the same(ish) name as your branch?

[briansmith]

@jamesmunns I could definitely do that. However, arm-unknown-linux-gnueabi is at 2.19 already and arm-unknown-linux-gnueabihf is at 2.27. I don't see why this particular target should have a lower glibc version than the other two. Also, Ubuntu 12.04 is EOL and will be at its end of extended security maintenance period in 3 months (April 2019), i.e. Ubuntu 12.04 is basically dead.

Also, personally I'd like to avoid supporting ARM with the ancient glibc in my projects because, without a way to detect NEON at runtime, there are significant performance and security challenges with my project. That is, when NEON is available, my project is not only faster but more secure. (This is also true for OpenSSL and similar, for the same reasons.)

So, with that in mind, do you think it makes sense to have two arm-unknown-linux-gnueabi images?

[jamesmunns]

Personally, I am not sure, and your reasoning is definitely sound. I think @japaric has been most vocal about backwards compatibility, so I'll let him chime in on this. We'll need to wait to trigger the CI anyway, so we can avoid a timeout.

[briansmith]

Some relevant bug reports:

• armv7-unknown-linux-gnuhf requires glibc >= 2.15, raspbian only has 2.13 rust-lang/rust#37562: @japaric said "I was under the impression that stable Raspbian was already shipping with 2.19; I may be wrong -- I'm not following Raspbian closely."

• rustc and cargo binaries crash on startup on ARM with glibc, because libpthread is loaded too late rust-lang/rust#35843 (comment): "Using a glibc-2.16/gcc-4.9 cross toolchain I can produce good rustc binaries. That seems like the smallest bump we can make because I can't get crosstool-ng to produce a glibc-2.15/gcc-4.9 toolchain." That change was merged, so Rust itself requires at least glibc 2.16 on these targets, AFAICT. Therefore it's no longer useful to try to support 2.15.

According to the getauxval() man page (http://man7.org/linux/man-pages/man3/getauxval.3.html), "The getauxval() function was added to glibc in version 2.16."

So, if we think that 2.19 is too high, we could find some way to use 2.16. However, I don't know how to get cross to use 2.16.

[gnzlbg]

FWIW the std::detect module works much better if getauxval is always available. We have a workaround in place for when that is not the case, but that is something that we might want to stop shipping with libstd by default. That is, applications that need this workaround would need to re-compile libstd with some extra features enabled, or use the std_detect crate directly.

[siscia]

Just to chin in, I am trying to create an image to suport GLIBC2.14 on x86_64 on Linux

This is necessary beceause the Linux AMI on aws still use the 2.14

I don't know if in embedded world there is the same need...

[gnzlbg]

We can always provide two (or more) images of each target, targeting different glibc versions with different target triples, but that does not hide the fact that the whole Rust toolchain is tested for one version only, and if any other target appears to work, that's probably just pure luck.

[briansmith]

Just to chin in, I am trying to create an image to suport GLIBC2.14 on x86_64 on Linux

This is necessary beceause the Linux AMI on aws still use the 2.14

I agree that glibc 2.14 is probably a reasonable choice for x86_64 and x86 for that reason. However, I don't think there's any compelling reason to require Aarch64 and ARM targets to use such an old glibc. This PR is only changing a single ARM target. Note again that other ARM targets are already using glibc 2.19 or higher.

[chris-ricketts]

In order to get bindgen to work in my build script I had to update Ubuntu from 12.04 to 14.04. Not sure if this is linked to glibc but it was required to bump the LLVM version from 2.9 to 3.4. Otherwise bindgen would fail with error: unsupported option '--target=armv7-unknown-linux-gnueabihf' when building with cross build --target=armv7-unknown-linux-gnueabihf.

[japaric]

Thanks for the PR. We are not going to bump glibc versions until we are ready to release v0.2.0 since it's a breaking change (see #164 (comment) for details).

As this is not currently actionable I'm going to close this PR to clear the queue.