I'm trying to compile cmake version 3.0.2 on GCC 4.9.2 but I'm getting the error message
/home/DrNo/cmake-3.0.2/Bootstrap.cmk/cmake: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /home/DrNo/cmake-3.0.2/Bootstrap.cmk/cmake)
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
I've taken a look at the ABI strings(?) in libstdc++.so.6 and can't find GLIBCXX_3.4.15:
$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
I've tried cmake compiling versions 3.0.0, 3.0.1, 3.0.2 and 3.7.2 but all require GLIBCXX_3.4.15, so it looks like I'm going to have to upgrade my version of GCC on this system (CentOS), which I don't want to because I've built this project on another system (Ubuntu with prepackaged cmake 3.0.2) with GCC 4.9.2.
Is it possible to have two GCC installs. A more recent one to build cmake and GCC 4.9.2 to build the rest of the project.
I hope you managed to get rid of the problem i am just leaving this comment here as a future reference:
I did have a similar problem when compiling cmake version 3.10.0 on gcc4.1.2 . I looked at my LD_LIBRARY_PATH and saw that there was a path from a former gcc version.
I simply set it to the correct path something along the lines gcc_4.1.2/linux50_64/lib64 via setenv. Nifty trick I learned was using setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}/your/path/here: which basically appends your path to the everything inside LD_PATH_LIBRARY variable.
Related
I recently updated my gcc version on CentOS from 4.7 to 5.4, but now I am getting the following error when I compile my program
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found
I found some solutions , but I am still not able to fix the issue. These are the paths I found with whereis gcc
gcc: /usr/bin/gcc /usr/lib/gcc /usr/local/bin/gcc /usr/local/lib/gcc /usr/libexec/gcc /usr/share/man/man1/gcc.1.gz
and used this libstdc package for CentOS.
Try export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/usr/local/lib64:/usr/lib64
Maybe for someone it will be helpful:
I installed devtoolset-7 but there was no GLIBCXX_3.4.21, and maximum version was GLIBCXX_3.4.19. Long time I was looking for the solution. What worked for me: I cloned gcc 7.3 repo, made build and install. Then copied libstdc++.so.6 and libstdc++.so.6.0.24 to devtools-7, lib64 folder and it became work.
I didn't have sudo access to my CentOS machine, so I installed gcc with conda. If you installed gcc with conda the above answer won't work.
check your gcc installation path as:
$ which gcc
output:
/home/ags/miniconda3/envs/GE/bin/gcc
This tells that gcc is installed in GE conda environment, now export LD_LIBRARY_PATH as the path to lib directory this environment.
export LD_LIBRARY_PATH=/home/ags/miniconda3/envs/GE/lib:$LD_LIBRARY_PATH
Hope this helps.
find your gcc installed location and update LD_LIBRARY_PATH
for example
/usr/local/gcc/7.2.0/
setenv LD_LIBRARY_PATH /usr/local/gcc/7.2.0/lib64/:$LD_LIBRARY_PATH
Simply your libstdc++.so.6 not including GLIBCXX_3.4.21, so you need to replace that library.
When I examine libstdc++.so.6.0.28 with strings libstdc++.so.6.0.28 | grep GLIBCXX the output is:
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_3.4.20
GLIBCXX_3.4.21
GLIBCXX_3.4.22
GLIBCXX_3.4.23
GLIBCXX_3.4.24
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_3.4.27
GLIBCXX_3.4.28
GLIBCXX_DEBUG_MESSAGE_LENGTH
So recreate symbolic with libstdc++.so.6.0.28 will fix your problem (also fixed my problem ;)).
Building TensorFlow with gcc version 4.8.5 or 5.4.0 gives an error:
bazel-out/host/bin/external/protobuf/protoc: /lib64/libstdc++.so.6:
version `GLIBCXX_3.4.20' not found (required by
bazel-out/host/bin/external/protobuf/protoc)
Tried to add linker flags in CROSSTOOL.tpl file in Tensorflow, however it didn't help.
You built your app with version of GCC that's newer than your host GCC. So your app uses symbols which are not present in host libstdc++ which causes runtime linker to fail.
You can solve this by linking your app with -Wl,-rpath,path/to/new/libs or setting LD_LIBRARY_PATH appropriately.
I already have GCC and Gfortran installed. It is gcc version 4.1.2 20080704 (Red Hat 4.1.2-52). However, I am trying to install a more recent gfortran compiler. Here is what I did so far. From the http://gfortran.meteodat.ch/download/x86_64/ I downloaded the nightly "gcc-trunk.tar.xz" and I extracted it into the directory "opt." This created the directory "gcc-trunk". I then downloaded the "gcc-5-infrastructure.tar.xz" and extracted it into "gcc-trunk." I then input
PATH="$HOME/gcc-trunk/bin":$PATH
MANPATH="$HOME/gcc-trunk/share/man"
LD_LIBRARY_PATH="$HOME/gcc-trunk/lib64":"$HOME/gcc-trunk/lib":$LD_LIBRARY_PATH
on bash. I then tried to verify whether gfortran installed correctly with
/path_name/gfortran -v
However, I get the message GLIBC_2.11' not found (required by /path_name/bin/gfortran). I am not sure what is the problem. What should I do?
The gfortran binary you downloaded was built against a newer version of glibc than the one you have installed on your system.
You can solve this problem e.g. by
Acquiring a gfortran binary built against an older version of glibc
Building GCC from source
Upgrade to a newer distro with a newer glibc
I am trying to build GraphChi on OS X Yosemite but get the following error:
fatal error: 'omp.h' file not found
From this question - How to include omp.h in OS X? - I learned that Yosemite uses Clang instead of gcc, which does not include omp.h.
$ which gcc
/usr/bin/gcc
$ gcc -v
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.1.0
Thread model: posix
Next, I installed gcc via Homebrew
$ brew info gcc
gcc: stable 4.9.2 (bottled)
http://gcc.gnu.org
/usr/local/Cellar/gcc/4.9.2_1 (1092 files, 177M)
Built from source with: --without-multilib
and updated $PATH to include the path to the new gcc version
$ echo $PATH
/usr/local/Cellar/gcc/4.9.2_1:usr/local/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin
however, gcc -v and which gcc still point to the old version, and building GraphChi still doesn't work due to the missing omp.h file
Does anyone know what else I need to do?
Update
locate omp.h returned:
/usr/local/Cellar/apple-gcc42/4.2.1-5666.3/lib/gcc/i686-apple-darwin11/4.2.1/include/omp.h
/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/gcc/x86_64-apple-darwin14.1.0/4.9.2/include/omp.h
/usr/local/Cellar/gfortran/4.8.2/gfortran/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2/include/omp.h
my ~/.profile:
export PATH=/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/gcc/x86_64-apple-darwin14.1.0/4.9.2/include:/usr/local/Cellar/gcc/4.9.2_1/bin:usr/local/bin:/opt/local/bin:/opt/local/sbin:$PATH
I solved this with installing gcc with homebrew:
brew install gcc --without-multilib
and then building the source code with
CC=gcc-5 CXX=g++-5 cmake ..
CC=gcc-5 CXX=g++-5 make -j7
Once you have installed gcc-4.9 with homebrew, it will automatically be in your path. To use OpenMP, you just need to make sure you are using the newly installed gcc-4.9, and it will be able to find omp.h.
In the case of GraphChi, you will have to go change line 3 of the Makefile to be gcc-4.9. From there, running make should just work. They describe this in their README, but at least the version they describe is out of date https://github.com/GraphChi/graphchi-cpp#problems-compiling-on-mac.
clang does not support OpenMP yet. Also gcc by default links to Apple's LLVM clang compiler (not the GCC installed from brew).
Instead gcc-4.9 would link to GCC. I think if -fopenmp is specified omp.h is included automatically.
It is possible to manually build a version of clang with OpenMP support, see http://clang-omp.github.io
You shouldn't add the include path to PATH; instead, specify it as CFLAGS, including the -I option. You can export the CFLAGS variable, or set it on the fly.
Depending on how you compile things, you could do
CFLAGS=-I/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/gcc/x86_64-apple-darwin14.1.0/4.9.2/include/omp.h gcc <whatever>
Of course, in this case you can specify it directly on the gcc command (as -I/usr/local/....), but the CFLAGS variable also works with configure (as configure often won't have an option to specify where it should look for specific include files); probably with make, or even for those installing a Python package: CFLAGS=-I... pip install <some-package>.
Other flags to consider are
CXXFLAGS: C++ specific pre-processor flags
LDFLAGS: linker specific flags (e.g. LDFLAGS=-L/some/path/... for linking with dynamic libraries).
CC: specify the C compiler to use. This is an easy way to avoid the built-in gcc alias for clang on OS X. Just use CC=/usr/local/bin/gcc-4 make or similar.
CXX: specify the C++ compiler to use.
I have GCC 4.1.2 and like to build CLANG / LLVM using this GCC compiler version ony. I need source to source translation library so that I can modify my existing source code for some requirement.
Initially I faced issues regarding usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found during LLVM / CLANG make. So in downloaded and build GCC 4.5.0 and installed at a local path. I found that libstdc++.so.6 of GCC 4.5.0 has GLIBCXX_3.4.9 version. Since I wanted to compile using GCC 4.1.2 I set my dynamic library path as:
setenv LD_LIBRARY_PATH /local/gcc-4.5.0/lib64:$LD_LIBRARY_PATH
And stated the make again after 'make clean'. Now that error did not occur.
However I am facing issues while compiling 'Compiler-RT' modules. I am not sure for which purpose Compiler-RT module is required but it seems LLVM and CLANG has compiled well.
Is it possible that I can exclude Compiler-RT from download , build and installation:
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
Build LLVM and Clang only
Is it right to set my shared library path to use libstdc++.so.6 of GCC 4.5.0 and is Compiler-RT is a madatory step to download and build it with CLANG / LLVM
I found this sample code here - do I require Compiler-RT - I don't see reference to same but just wanted to confirm?