Snapshots no longer work on RedHat 5.5 #9545
Comments
|
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 |
|
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? |
|
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. |
|
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. |
|
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. |
|
@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. |
|
This is worse than I thought 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. |
|
Just came across the same issue. |
|
@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. |
|
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. |
|
Maybe musl is going to be the way forward… |
|
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. |
|
@gitfoxi libstdc++ is pretty easy to install (just need to grab a new enough gcc, and there are packages for it on RHEL 5) |
|
@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. |
|
cc #7283 re musl. |
This is the first linux snapshot created on our new CentOS 5.10 builders. Closes rust-lang#9545
|
The latest snapshot (being added in #17329) should fix this issue. |
|
I've built rust successfully on my RHEL 5.5 machine, and a basic "hello world" is working. Thank you very much! |
Release Notes: ``` v1.38.47: 10/02/2019 -------------------- - Add support for FETCH API in WASM backend. This doesn't support FETCH in the main thread (`USE_FETCH_WORKER=0` is enforced). rust-lang#9490 - Redefine errno values to be consistent with wasi. This will let us avoid needing to convert the values back and forth as we use more wasi APIs. This is an ABI change, which should not be noticeable from user code unless you use errno defines (like EAGAIN) *and* keep around binaries compiled with an older version that you link against. In that case, you should rebuild them. See rust-lang#9545. - Removed build option `-s ONLY_MY_CODE` as we now have much better solutions for that, like building to a wasm object file or using `STANDALONE_WASM` etc. (see https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone). - Emscripten now supports the config file (.emscripten) being placed in the emscripten directory rather that the current user's home directory. See rust-lang#9543 ```
Bump minor version of emsdk to 1.38.47 Release Notes: ``` v1.38.47: 10/02/2019 -------------------- - Add support for FETCH API in WASM backend. This doesn't support FETCH in the main thread (`USE_FETCH_WORKER=0` is enforced). rust-lang#9490 - Redefine errno values to be consistent with wasi. This will let us avoid needing to convert the values back and forth as we use more wasi APIs. This is an ABI change, which should not be noticeable from user code unless you use errno defines (like EAGAIN) *and* keep around binaries compiled with an older version that you link against. In that case, you should rebuild them. See rust-lang#9545. - Removed build option `-s ONLY_MY_CODE` as we now have much better solutions for that, like building to a wasm object file or using `STANDALONE_WASM` etc. (see https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone). - Emscripten now supports the config file (.emscripten) being placed in the emscripten directory rather that the current user's home directory. See rust-lang#9543 ``` Motivated by changes to errno values which are currently out of sync with those in libc crate which uses wasi values already. Helps with rust-lang#72808 and rust-lang#75532.
Bump minor version of emsdk to 1.38.47 Release Notes: ``` v1.38.47: 10/02/2019 -------------------- - Add support for FETCH API in WASM backend. This doesn't support FETCH in the main thread (`USE_FETCH_WORKER=0` is enforced). rust-lang#9490 - Redefine errno values to be consistent with wasi. This will let us avoid needing to convert the values back and forth as we use more wasi APIs. This is an ABI change, which should not be noticeable from user code unless you use errno defines (like EAGAIN) *and* keep around binaries compiled with an older version that you link against. In that case, you should rebuild them. See rust-lang#9545. - Removed build option `-s ONLY_MY_CODE` as we now have much better solutions for that, like building to a wasm object file or using `STANDALONE_WASM` etc. (see https://github.com/emscripten-core/emscripten/wiki/WebAssembly-Standalone). - Emscripten now supports the config file (.emscripten) being placed in the emscripten directory rather that the current user's home directory. See rust-lang#9543 ``` Motivated by changes to errno values which are currently out of sync with those in libc crate which uses wasi values already. Helps with rust-lang#72808 and rust-lang#75532.
…, r=Manishearth Don't lint unstable moves in `std_instead_of_core` Fixes rust-lang#9515 changelog: [`std_instead_of_core`]: No longer suggests unstable modules such as `core::error`
Our snapshot builder is running CentOS 6.
The text was updated successfully, but these errors were encountered: