dist-x86-linux: switch to CentOS 6

[ishitatsuyuki]

This brings the modern toolchain into the build system and hopefully speeds up the things.

CentOS 5 (and Ubuntu 12.04) is about EOL, so let's switch a week before they expires.

glibc version watch:

status	distro	version
dead	CentOS/RHEL 5	2.5 oldest
	CentOS/RHEL 6	2.12 oldest active
dead	Debian 6	2.11
	Debian 7	2.13
dead	Ubuntu 12.04	2.15
	Ubuntu 14.04	2.19

DO NOT MERGE - Remove the testing commit before proceeding

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[TimNN]

@ishitatsuyuki: To have travis test this, you can temporarily add ALLOW_PR=1 to the env: IMAGE=dist-x86-linux DEPLOY=1 line of .travis.yml.

Also, all the now unused shell scripts should probably be deleted.

[TimNN]

I'm not completely sure, but as I understand this scl enable sets up the environment to use the specified tools? In that case this may not work correctly since the ./configure script is ran outside of that environment, I think.

[ishitatsuyuki]

Good catch. Let me find a fix for that.

[ishitatsuyuki]

cmake3 seems to be available in EPEL, will add it tomorrow.

[alexcrichton]

What is the motivation for doing this? Do we have active problems we need fixing with the centos 5 image? I'd ideally prefer to have strong motivation for raising our glibc requirement as that can have wide ramifications.

[alexcrichton]

(oops didn't mean to close)

[ishitatsuyuki]

My personal reason is distro expiry. You don't need to maintain binary compatibility for those unsupported distros, since it's possible to build from source. (I don't think a sysadmin can live without SNI now)

This doesn't break Ubuntu 12.04, so there's no concern of breaking the shitty Travis infrastructure.

GCC 6 doesn't seem to perform super well than 4, but anyway I guess newer toolchains are better.

[alexcrichton]

but anyway I guess newer toolchains are better

This is not a reason to require a new glibc version out of the blue, is there a technical reason for this upgrade?

[ishitatsuyuki]

This is a distro upgrade alongside with new backported toolchains (made possible with SCL in CentOS 6). We no longer need to hack from source for another LLVM requirement bump.

CentOS 5 is about to expire. Debian 6 already expired. There's not so many concern of breakage, and we never need to support those EOL distros. (I have already mentioned that they can build things from source)

If I'm correct, this will land 3 months later in stable. I believe it's an enough margin to upgrade.

[sfackler]

we never need to support those EOL distros

Why?

[ishitatsuyuki]

@sfackler whoever will run nightly(rustup) on CentOS 5? Anyway, I have already mentioned that they can compile everything by themselves.

End of life is what devs can forget, we don't need to show effort to support them.

[ishitatsuyuki]

Seems we need a multilib compiler.

[ishitatsuyuki]

Abandoning due to no SCL for multilib. I choose continuing with existing infra.

[cuviper]

You don't need to maintain binary compatibility for those unsupported distros, since it's possible to build from source.

Note that building rustc from source still requires bootstrap binaries for stage0. If rust-lang.org's binaries stop supporting older glibc, then such users can't directly build from source either. They would have to go through the cross-compile steps from a system that does have the newer glibc to run stage0.