Skip to content

Snapshots no longer work on RedHat 5.5 #9545

Description

@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.

Activity

  1. thestinger commented on Sep 26, 2013

    @thestinger
    Contributor

    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).

  2. flaper87 commented on Feb 17, 2014

    @flaper87
    Contributor

    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?

  3. thestinger commented on Aug 16, 2014

    @thestinger
    Contributor

    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.

  4. gitfoxi commented on Sep 8, 2014

    @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.

  5. eminence commented on Sep 8, 2014

    @eminence
    Contributor

    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.

  6. gitfoxi commented on Sep 8, 2014

    @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.

  7. gitfoxi commented on Sep 9, 2014

    @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.

  8. buster commented on Sep 12, 2014

    @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?

  9. brson commented on Sep 12, 2014

    @brson
    ContributorAuthor

    @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.

  10. carllerche commented on Sep 13, 2014

    @carllerche
    Contributor

    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.

  11. pcwalton commented on Sep 13, 2014

    @pcwalton
    Contributor

    Maybe musl is going to be the way forward…

  12. carllerche commented on Sep 13, 2014

    @carllerche
    Contributor

    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.

  13. carllerche commented on Sep 13, 2014

    @carllerche
    Contributor

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

  14. wycats commented on Sep 14, 2014

    @wycats
    Contributor

    @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.

  15. huonw commented on Sep 16, 2014

    @huonw
    Contributor

    cc #7283 re musl.

  16. added a commit that references this issue on Sep 17, 2014
    c4a1c38
  17. alexcrichton commented on Sep 17, 2014

    @alexcrichton
    Member

    The latest snapshot (being added in #17329) should fix this issue.

  18. eminence commented on Sep 19, 2014

    @eminence
    Contributor

    I've built rust successfully on my RHEL 5.5 machine, and a basic "hello world" is working. Thank you very much!

  19. added a commit that references this issue on Aug 16, 2020
  20. added a commit that references this issue on Aug 16, 2020
  21. added a commit that references this issue on Oct 6, 2022
  22. added a commit that references this issue on Aug 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    O-linuxOperating system: Linux

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions