Snapshots no longer work on RedHat 5.5

[brson]

LSB Version:
:core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: RedHatEnterpriseServer
Description:    Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Release:        5.5
Codename:       Tikanga

> uname -a
Linux sulfursim 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010
x86_64 x86_64 x86_64 GNU/Linux

x86_64-unknown-linux-gnu/stage0/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd.so
x86_64-unknown-linux-gnu/stage0/bin/rustc: /lib64/libc.so.6: version
`GLIBC_2.7' not found (required by

/rd/gen/lxd/do_not_delete/devel/rust-0.8/x86_64-unknown-linux-gnu/stage0/bin/../lib/librustrt.so)
x86_64-unknown-linux-gnu/stage0/bin/rustc: /lib64/libc.so.6: version
`GLIBC_2.6' not found (required by

/rd/gen/lxd/do_not_delete/devel/rust-0.8/x86_64-unknown-linux-gnu/stage0/bin/../lib/librustllvm.so)
make: ***
[x86_64-unknown-linux-gnu/stage0/lib/rustc/x86_64-unknown-linux-gnu/lib/libstd.so]
Error 1

Our snapshot builder is running CentOS 6.

[thestinger]

I think we would have to build on CentOS5 to reliably support RHEL5. Perhaps we should just call it unsupported as we do for old OS X versions?

The only alternative I can think of is actually getting a C library like musl working for Rust and statically linking it in the snapshot builds. Sadly, glibc itself doesn't really support static linking (and is huge).

[flaper87]

I agree with @thestinger. I think we could move forward to just supporting RHEL>=6.4

@brson Do you agree? Can this bug be closed?

[thestinger]

By the way, my earlier mention of musl isn't actually relevant. It only runs on kernels newer than the one offered by RHEL5 anyway.

[gitfoxi]

The thing is that RHEL systems that many people use at work are upgraded rarely because stability is important in complex-shared setups and utmost in production. If I can't get Rust for RHEL5 then it will literally be 5 years before I can use Rust at work.

It's not like your macbook where you might as well take the latest OSX after a month or two. We're currently still moving systems to RHEL5 and shutting down HPUX11 and RHEL3 sometime next year. RHEL6 is for new projects only and not used for anything in operations.

The thing is that it's kind of a nightmare imagining how you could even get Rust going again on RHEL5 since you need an already-working Rust to bootstrap compiling. You'd have to go back to the last snapshot that worked and start trying to build incrementally-newer versions until you got up-to-date.

Maybe you could start with a chroot configured like RHEL6 and somehow work backwards.

[eminence]

This per precisely the problem for me as well. I would love to be able to write a few tools in rust, and introduce some coworkers to the language.

[gitfoxi]

@thestinger I think your idea of using musl is a good one. I haven't used it before but the FAQ says it works on 2.6 kernels and RHEL5 is 2.6.18. I will see if I can build it. The other thing, though is that it's not just glibc but every one of the dependencies which depend on glibc -- which is likely all of them -- will have to be built with musl. How big that job is depends on how many dependencies Rust has. I haven't had the pleasure of building from source yet but I imagine it's quite a few.

Still, some effort is warranted to avoid freezing out a large fraction of professional programmers.

Update: musl builds with no problems in RHEL5. Too bad it doesn't seem to come with a test suite. Now to imagine how to build all those dependencies. The big problem still is that Rust can't bootstrap in RHEL5 environment so I'll still have to make in RHEL6.

[gitfoxi]

This is worse than I thought

[m@rhel rust-nightly-i686-unknown-linux-gnu]$ LD_LIBRARY_PATH=lib bin/rustc
bin/rustc: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by lib/librustc_llvm-4e7c5e5c.so)
[m@rhel rust-nightly-i686-unknown-linux-gnu]$ cat /etc/redhat-release 
CentOS release 6.5 (Final)

Rust snapshot doesn't work on CentOS 6.5 which is equivalent to the final release of RHEL6. How am I the first one to notice? The only newer platform is RHEL7 which was released in June of this year. This platform requirement makes no sense. LLVM works fine on Redhat 5. Julia -- also based on LLVM -- compiles on RHEL5 without a hitch. Why does LLVM want GLIBCXX bla bla anyway? Doesn't clang++ ship it's own stdc++ library?

Update: I went through the build process. Tried a few times with different Linuxs (Linuxi?) and was only successful using an up-to-date Arch. I think it may never be practical to reduce the build requirements to enable building on less bleeding-edge distros. What can and should be done is to cross-compile targeting older or alternative libc and ship binaries with own libstdc++ or libc++. The build process makes LLVM but not clang or clang++. I think the way forward would be to build clang (or just use Arch's if it doesn't need patching) and then use it's cross compiling capabilities along with the kernel sources, binutils and glibc from Centos5 srpms (or uclibc or musl might be good alternatives to old glibc; maybe even glibc can be configured to not use interfaces past 2.12; I'm not an expert). Anyway, it's an all-day project and I'll have to see if I'm still interested this weekend.

Question: If the build-system requirements are bleeding-edge, is there any particular reason to build LLVM from scratch rather than using the very up-to-date one that always exists on Arch? Answer: Yes, duh. You have to cross-compile LLVM and all of it's dependencies too in order to ship a glibc-free libllvm.so.

This may also be a good time to integrate some patchelf technology. If most linux installations will be binary-only then it's good to let the user select where to install it. Some non-root users will want to try it in their home directory and some sysadmins would prefer to install to /opt/rust rather than piling everything up in /usr/local.

[buster]

Just came across the same issue.
I'm very surprised to find that rust aparently doesn't even run on RHEL6.
Is there a way to compile a rust program for RHEL6 or 5?

[brson]

@gitfoxi Are you sure that snapshots don't work on RHEL 6.5? Nightlies I understand since they link libstdc++ dynamically, but snapshots link it statically. If snapshots work you should be able to build from source.

[carllerche]

We use to use Rust in production, however we have a non trivial number of customers on RHEL 5 (and CentOS). The fact is that 5.10 came out less than a year ago and is not scheduled for EOL until sometime in 2017.

If Rust decides to not support such platforms, it will mean that we will not be able to use it and I suspect that a large number of potential users will be in the same boat.

I would like to add that we have figured out work arounds to run builds on CentOS 5.10 for now, but we really need rustc to properly support the platform.

[pcwalton]

Maybe musl is going to be the way forward…

[carllerche]

So, I'm a bit confused about why musl is needed. When I looked, in the rust nightly there was only 1 symbol that depended on glibc 2.6, and that was conditionally detected when llvm when compiled on a box that had glibc 2.6.

If rust was compiled on CentOS 5.10, it should "just work".

I actually got it working (using really bad hacks), so it should be doable without embedding libc.

[carllerche]

@gitfoxi libstdc++ is pretty easy to install (just need to grab a new enough gcc, and there are packages for it on RHEL 5)

[wycats]

@carllerche @pcwalton honestly, I'm pretty sure that getting musl working properly will be a win, regardless of whether it is possible to build rustc on old boxes. The ability to (optionally) build a totally self-contained native binary from Rust, especially if the total file size remains plausible, would be very nice.

[huonw]

cc #7283 re musl.