dist-x86_64-linux: upgrade to CentOS 6

[ishitatsuyuki]

Now that CentOS 5 is EOL, we don't have to care too much about them. See #40848

i686? I don't care. jk, I'm planning to make them a crosstool-ng target so we don't need to care about multilib package miss or hard to obtain glibc versions.

[rust-highfive]

r? @aturon

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

[ishitatsuyuki]

Build looks fine so far. Remove the commit when ready.

[aturon]

cc @alexcrichton @brson @TimNN @aidanhs

[aturon]

Note that, as discussed in #40848, should a move has implications for our glibc requirements.

[alexcrichton]

I personally do not feel that we're ready to do this yet. We don't have an understanding of what the impact of this will be on downstream consumers of Rust. For now our builds are continuing to work, and I think we need to start thinking about moving to a higher glibc requirement for sure. I don't think there's much urgency though at this time.

My preferred method for dealing with this would be:

• Make an announcement that we're considering increasing the minimum glibc requirement.
  • Clearly state what the impact of such a change would be
  • Ask others to test what version they have locally to see if it'll work
• After awhile if everyone's on board announce that we're increasing the glibc requirement
• Then merge a PR which increases the glibc requirement.

I'll also note that this PR is not currently passing tests (travis is failing) and this is likely to run afoul of #37874 on 32-bit which would necessitate compiling our own version of binutils.

[ishitatsuyuki]

I have added openssl-devel which will hopefully fix the build. (It should fail on uploading artifacts, due to no IAM credentials anyway.) The binutils with devtoolset-6 is surely bleeding edge and I don't have concerns with that.

I will create a thread on internals.rlo to have some space for discussion.

When this propagates to beta it will surely break the i686 bootstrap, so I will file another PR for changing i686 to crosstool-ng (on decent distro) soon.

[alexcrichton]

We should not need openssl-devel the intention is that we compile our own OpenSSL and use it locally. The build system manages this and has a pinned version of OpenSSL to compile against. We do not want to link against the system LLVM.

I would also personally wish to see i686 working before merging support for x86_64, although both I believe need to happen after a public discussion. A thread on internals sounds good to me.

[ishitatsuyuki]

I believe cargo-vendor is attempting to link to system openssl. There's no problem doing that, since it's a build time tool and this is only required for the source builder. The build passed, so let's leave it working.

…

On Tue, Apr 18, 2017, 10:10 AM Alex Crichton ***@***.***> wrote: We should not need openssl-devel the intention is that we compile our own OpenSSL and use it locally. The build system manages this and has a pinned version of OpenSSL to compile against. We do not want to link against the system LLVM. I would also personally wish to see i686 working before merging support for x86_64, although both I believe need to happen after a public discussion. A thread on internals sounds good to me. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#41339 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AL0MB0YcJiASpPZnxaI7Sdgm2ATN6Avsks5rxA1xgaJpZM4M_ImB> .

[ishitatsuyuki]

I have rebased and this can be merged at any time.

Here's the thread for discussion. Maybe putting this on newsletter will attract people who are using old glibc.

I'm currently working on i686 crosstool-ng config, stay tuned.

[alexcrichton]

Ah yes, that makes sense for cargo-vendor. Also thanks for opening a thread on internals, I've left a comment there.

[ishitatsuyuki]

I'm closing this again since I'm unable to get a good i686 image and there's some demand for glibc <2.12 (SLES 11 which is alive).