libstdc++.so.6 version glibcxx_3.4.15' not found centos 6.5

[LeoJavaAI]

I got this error while using the latest version on rust 0.11.

gcc is installed not sure what i need to do to resolve it

[alexcrichton]

The is likely because a fairly new version of gcc is required, due to LLVM requiring C++11 support. I would recommend installing gcc 4.7 or above.

We build our snapshots and nightlies on a centos 6 machine, and I sadly had to compile our own gcc to get the right C++11 support.

Another option is to build rust elsewhere with the --enable-llvm-static-stdcpp configure option, and then you shouldn't have to worry about this error.

In the meantime, however, there's sadly not much we can do about this, so I'm going to close this issue as not very actionable.

[LeoJavaAI]

Hi Alex,

I have 4.8.1, I still get

oxidize: x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc
make: *** [x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.rustc] Killed

on rust 0.10

[LeoJavaAI]

Tried the second option but

configure: error: Option '--enable-llvm-static-stdcpp' is not recognized

[alexcrichton]

Reopening to investigate.

• Can you explain a bit more about your setup?
• Did you install 4.8.1 via a package manager or did you compile it yourself?
• I would recommend compiling from master, not 0.10 (this option didn't exist then)

[LeoJavaAI]

• Centos6.5, liux kernel 2.6.32-042stab072.10 x86_64, gcc version full outpu https://gist.github.com/Leo-g/7f1081ebdeedce9030f8
• I had 4.7.7, but decided to upgrade to 4.8.1 using the devtools repo mentioned here http://superuser.com/questions/381160/how-to-install-gcc-4-7-x-4-8-x-on-centos

*I downloaded the 0.11 binary and ran the script but i get the below error

/home/leo/rust/rust-0.11.0-x86_64-unknown-linux-gnu//bin/rustc: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /home/leo/rust/rust-0.11.0-x86_64-unknown-linux-gnu/bin/../lib/librustc-a9826c4a-0.11.0.so)

Will try to compile from master

[alexcrichton]

Are you sure you have the right entry in LD_LIBRARY_PATH? If you run ldd over the rustc executable it should have an entry for libstdc++.so.6 pointing into thte directory you installed 4.8.1 into.

[LeoJavaAI]

will check that

While I tried to compile from master with --enable-llvm-static-stdcpp, I get the below error on make

make: llvm
make[1]: Entering directory /home/leo/rust/rust/x86_64-unknown-linux-gnu/llvm' make[2]: Entering directory/home/leo/rust/rust/x86_64-unknown-linux-gnu/llvm/lib/Support'
llvm[2]: Compiling APFloat.cpp for Release+Asserts build
/tmp/ccDIQhHL.s: Assembler messages:
/tmp/ccDIQhHL.s:350: Error: expecting string instruction after rep' /tmp/ccDIQhHL.s:354: Error: expecting string instruction afterrep'
/tmp/ccDIQhHL.s:779: Error: expecting string instruction after rep' /tmp/ccDIQhHL.s:1647: Error: expecting string instruction afterrep'
/tmp/ccDIQhHL.s:1659: Error: expecting string instruction after rep' /tmp/ccDIQhHL.s:1663: Error: expecting string instruction afterrep'
make[2]: *** [/home/leo/rust/rust/x86_64-unknown-linux-gnu/llvm/lib/Support/Release+Asserts/APFloat.o] Error 1
make[2]: Leaving directory /home/leo/rust/rust/x86_64-unknown-linux-gnu/llvm/lib/Support' make[1]: *** [all] Error 1 make[1]: Leaving directory/home/leo/rust/rust/x86_64-unknown-linux-gnu/llvm'
make: *** [/home/leo/rust/rust/x86_64-unknown-linux-gnu/llvm/Release+Asserts/bin/llvm-config] Error 2

[alexcrichton]

This sounds like there are a number of issues going on here, some of which are getting conflated with others. Here's what I would recommend doing:

1. Make sure you have the right libstdc++.so installed somewhere. This will be in a gcc 4.7+ installation I imagine.
2. Ensure that the directory for that library is in LD_LIBRARY_PATH
3. Make sure the rust nightly doesn't work with the correct LD_LIBRARY_PATH. If you run ldd over the rustc binary, it should print the right path to libstdc++.so (the one you found in step 1)
4. Download and build rust with no options, make sure this works. (only if nightly doesn't work)
5. Download and build rust with --enable-llvm-static-stdcpp (only if nightly doesn't work).

[LeoJavaAI]

1. It is installed in /usr/lib64/libstdc++.so.6
   2.It is else it would not find /usr/lib64/libstdc++.so.6.
   3.ldd rustc
   ./rustc: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15'

So I did the follow
/usr/lib64/libstdc++.so.6 -> /opt/rh/devtoolset-2/root/usr/lib/gcc/x86_64-redhat-linux/4.8.1/libstdc++.so

ldd rustc
libstdc++.so.6 => not found

4 & 5 tried does not work, don't understand the string error?

Not sure how to proceed now,

[bearrito]

I can replicate all of the above issues and confirm none of the fixes work for me.

[Nercury]

I am trying to compile rust on CentOS 5.10. I have succesfuly compiled latest version of gcc for that, 4.7.4.
Before compiling rust, I run

export PATH=/opt/gcc-build-4.7.4/bin/:$PATH
export LD_LIBRARY_PATH=/opt/gcc-build-4.7.4/lib/

Everything builds ok until this line:

/opt/rust-src/x86_64-unknown-linux-gnu/llvm/Release+Asserts/bin/llvm-tblgen: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /opt/rust-src/x86_64-unknown-linux-gnu/llvm/Release+Asserts/bin/llvm-tblgen)

It looks like the script downloads rust bunary in stage0. When i try to run it, I get:

[root@vds bin]# ./rustc
./rustc: /lib64/libc.so.6: version `GLIBC_2.6' not found (required by ./rustc)

As suggested above, I can run ldd:

[root@vds bin]# ldd rustc
./rustc: /lib64/libc.so.6: version `GLIBC_2.6' not found (required by ./rustc)
        linux-vdso.so.1 =>  (0x00007fff39192000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3c71979000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f3c7176f000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f3c7156b000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f3c712e8000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3c710d9000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f3c70d80000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f3c71baa000)

It probably means that my OS is really, really old. However, I can't really change it very easily :). Any more suggestions?

[Nercury]

I can do this hack and get LLVM libraries to compile:

export LD_PRELOAD='/opt/gcc-build-4.7.4/lib64/libstdc++.so.6'

However, it fails as soon as it uses rustc binary built on more recent system:

cfg: build triple x86_64-unknown-linux-gnu
cfg: host triples x86_64-unknown-linux-gnu
cfg: target triples x86_64-unknown-linux-gnu
cfg: enabling more debugging (CFG_ENABLE_DEBUG)
cfg: host for x86_64-unknown-linux-gnu is x86_64
cfg: os for x86_64-unknown-linux-gnu is unknown-linux-gnu
cfg: using CC=gcc (CFG_CC)
cfg: no pandoc found, omitting PDF and EPUB docs
cfg: no llnextgen found, omitting grammar-verification
rustc: x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore
x86_64-unknown-linux-gnu/stage0/bin/rustc: /lib64/libc.so.6: version `GLIBC_2.6' not found (required by x86_64-unknown-linux-gnu/stage0/bin/rustc)
make: *** [x86_64-unknown-linux-gnu/stage0/lib/rustlib/x86_64-unknown-linux-gnu/lib/stamp.core] Error 1

It would be fine if I could build rustc myself (which I am trying to do), but rustc is required for that. So, at this point rust happens to be limited to systems with libc 2.6 or later.

[alexcrichton]

Nightlies are now built on CentOS 5.10 and statically link libstdc++, can you confirm that the binaries work for you now?

[MatejLach]

Trying to run this on my CentOS 6.5 server, I get:
./rustc: error while loading shared libraries: libnative-4e7c5e5c.so: cannot open shared object file: No such file or directory

[alexcrichton]

You need to be sure to have $prefix/lib in your LD_LIBRARY_PATH, that library is distributed with rust itself.

[MatejLach]

@alexcrichton Ooops, sure, forgot to do that.
It still doesn't seem to work however.
ldd rustc ./rustc: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.15' not found
Why it's rustc still expecting libstdc++ in /usr/lib64/ if it's statically linked?

[alexcrichton]

You may want to confirm that you're downloading the right binary due to our cloudfare syncing issues. This looks to be the same as #17194 though (which is confirmed fix), so I'm going to close this.

[MatejLach]

@alexcrichton So it was CF, works over here - thanks for working on this!