GLIBCXX_3.4.21 not found on CentOS 7 - gcc

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

Related

Why my Make file doesn't compiling in Mac and display ld: library not found for -lSystem? [duplicate]

I am getting a strange error when trying to compile a simple fortran-90 file using gfortran. I am working on a macOS mojave system. I have gfortran 8.2.0 installed and I checked to be sure of this by doing the following:
Input: gfortran --version
Output: GNU Fortran (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Which indicates that gfortran installed correctly and I also confirmed this by typing simply: gfortran, into the terminal, which returns:
gfortran: fatal error: no input files
compilation terminated.
However, when I try to compile my file like so:
gfortran hello.f90 -o hello.x
I get an error which reads:
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status
I've tried compiling in different ways and I also tried setting the LD_LIBRARY_PATH in .bash_profile as described by https://gcc.gnu.org/wiki/GFortranBinaries32Linux but I still get the same error. The gfortran directory has the pathname: /usr/local/gfortran, however another gfortran which is not a directory can be found in /usr/local/bin
Typing:
which gfortran
Outputs:
/usr/local/bin/gfortran
And a long list search of this directory:
Input: ls -l /usr/local/bin/gfortran
Output: lrwxr-xr-x 1 root wheel 32 15 May 14:07
/usr/local/bin/gfortran -> /usr/local/gfortran/bin/gfortran
How can I fix this where everything seems to be correctly installed?
Any help would be greatly appreciated!
On macOS Big Sur v11.1:
Relevant SO post: https://apple.stackexchange.com/questions/408999/gfortran-compiler-error-on-mac-os-big-sur
The fix is to add the stdlib to your $LIBRARY_PATH. For some reason or another it isn't in your standard $PATH anymore on 11.1.
export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
(or add it to login file and restart terminal).
I added this to my ~/.profile:
export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
export LIBRARY_PATH="$LIBRARY_PATH:$SDKROOT/usr/lib"
And it works.
I'll also chime in (19 Dec 2020) that I just updated from MacOS Mojave to Catalina and suddenly got this error.
It resolved itself with
brew reinstall gcc
brew reinstall gfortran
Update: I tried what was suggested and installed the gfortran build from the gcc package using homebrew which gave me a newer version of gfortran and my problem was fixed!
I had the same problem, but installing gfortran build from the gcc package using homebrew did not help. Instead, I installed the whole gcc using homebrew:
brew install gcc
and that solved the problem.
For those using MacPorts.
# Installed `gcc8` and `gcc_select`
sudo port install gcc_select gcc8
# then to create "gfortran" softlink to "gfortran-mp-8"
sudo port select --set gcc gcc8
# and added to my .profile
export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
I did ls -l /Library/Developer/CommandLineTools/SDKs/ and found that Xcode had installed one SDK for Catalina and one for Big Sur. I changed the soft link for MacOSX.sdk to point to the Catalina version.
Just placed this line at the end of .zshrc:
export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
and ran my Fortran code again to compile – success! The issue with -lSystem has been solved in my macOS system.
I had this problem, and I'd tried lots of thing to solve the problem, but only using these "both" commands solved it:
brew reinstall gcc
brew reinstall gfortran
I recently had this
ld: library not found for -lSystem
problem after upgrading Mac OS from v10 to v11 (Big Sur). I am using Xcode 12.3 and I used brew install gcc to install gfortran 10.2.0. I still saw the error after trying brew reinstall gcc. I was able to solve the problem using:
brew install gfortran
but I do not know why this works.

library not found for -lSystem - M1 MacBook - Radmc3d [duplicate]

I am getting a strange error when trying to compile a simple fortran-90 file using gfortran. I am working on a macOS mojave system. I have gfortran 8.2.0 installed and I checked to be sure of this by doing the following:
Input: gfortran --version
Output: GNU Fortran (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Which indicates that gfortran installed correctly and I also confirmed this by typing simply: gfortran, into the terminal, which returns:
gfortran: fatal error: no input files
compilation terminated.
However, when I try to compile my file like so:
gfortran hello.f90 -o hello.x
I get an error which reads:
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status
I've tried compiling in different ways and I also tried setting the LD_LIBRARY_PATH in .bash_profile as described by https://gcc.gnu.org/wiki/GFortranBinaries32Linux but I still get the same error. The gfortran directory has the pathname: /usr/local/gfortran, however another gfortran which is not a directory can be found in /usr/local/bin
Typing:
which gfortran
Outputs:
/usr/local/bin/gfortran
And a long list search of this directory:
Input: ls -l /usr/local/bin/gfortran
Output: lrwxr-xr-x 1 root wheel 32 15 May 14:07
/usr/local/bin/gfortran -> /usr/local/gfortran/bin/gfortran
How can I fix this where everything seems to be correctly installed?
Any help would be greatly appreciated!
On macOS Big Sur v11.1:
Relevant SO post: https://apple.stackexchange.com/questions/408999/gfortran-compiler-error-on-mac-os-big-sur
The fix is to add the stdlib to your $LIBRARY_PATH. For some reason or another it isn't in your standard $PATH anymore on 11.1.
export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
(or add it to login file and restart terminal).
I added this to my ~/.profile:
export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
export LIBRARY_PATH="$LIBRARY_PATH:$SDKROOT/usr/lib"
And it works.
I'll also chime in (19 Dec 2020) that I just updated from MacOS Mojave to Catalina and suddenly got this error.
It resolved itself with
brew reinstall gcc
brew reinstall gfortran
Update: I tried what was suggested and installed the gfortran build from the gcc package using homebrew which gave me a newer version of gfortran and my problem was fixed!
I had the same problem, but installing gfortran build from the gcc package using homebrew did not help. Instead, I installed the whole gcc using homebrew:
brew install gcc
and that solved the problem.
For those using MacPorts.
# Installed `gcc8` and `gcc_select`
sudo port install gcc_select gcc8
# then to create "gfortran" softlink to "gfortran-mp-8"
sudo port select --set gcc gcc8
# and added to my .profile
export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
I did ls -l /Library/Developer/CommandLineTools/SDKs/ and found that Xcode had installed one SDK for Catalina and one for Big Sur. I changed the soft link for MacOSX.sdk to point to the Catalina version.
Just placed this line at the end of .zshrc:
export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
and ran my Fortran code again to compile – success! The issue with -lSystem has been solved in my macOS system.
I had this problem, and I'd tried lots of thing to solve the problem, but only using these "both" commands solved it:
brew reinstall gcc
brew reinstall gfortran
I recently had this
ld: library not found for -lSystem
problem after upgrading Mac OS from v10 to v11 (Big Sur). I am using Xcode 12.3 and I used brew install gcc to install gfortran 10.2.0. I still saw the error after trying brew reinstall gcc. I was able to solve the problem using:
brew install gfortran
but I do not know why this works.

compiling F90 code on mac osx catalina: library issues [duplicate]

I am getting a strange error when trying to compile a simple fortran-90 file using gfortran. I am working on a macOS mojave system. I have gfortran 8.2.0 installed and I checked to be sure of this by doing the following:
Input: gfortran --version
Output: GNU Fortran (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Which indicates that gfortran installed correctly and I also confirmed this by typing simply: gfortran, into the terminal, which returns:
gfortran: fatal error: no input files
compilation terminated.
However, when I try to compile my file like so:
gfortran hello.f90 -o hello.x
I get an error which reads:
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status
I've tried compiling in different ways and I also tried setting the LD_LIBRARY_PATH in .bash_profile as described by https://gcc.gnu.org/wiki/GFortranBinaries32Linux but I still get the same error. The gfortran directory has the pathname: /usr/local/gfortran, however another gfortran which is not a directory can be found in /usr/local/bin
Typing:
which gfortran
Outputs:
/usr/local/bin/gfortran
And a long list search of this directory:
Input: ls -l /usr/local/bin/gfortran
Output: lrwxr-xr-x 1 root wheel 32 15 May 14:07
/usr/local/bin/gfortran -> /usr/local/gfortran/bin/gfortran
How can I fix this where everything seems to be correctly installed?
Any help would be greatly appreciated!
On macOS Big Sur v11.1:
Relevant SO post: https://apple.stackexchange.com/questions/408999/gfortran-compiler-error-on-mac-os-big-sur
The fix is to add the stdlib to your $LIBRARY_PATH. For some reason or another it isn't in your standard $PATH anymore on 11.1.
export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
(or add it to login file and restart terminal).
I added this to my ~/.profile:
export SDKROOT=$(xcrun --sdk macosx --show-sdk-path)
export LIBRARY_PATH="$LIBRARY_PATH:$SDKROOT/usr/lib"
And it works.
I'll also chime in (19 Dec 2020) that I just updated from MacOS Mojave to Catalina and suddenly got this error.
It resolved itself with
brew reinstall gcc
brew reinstall gfortran
Update: I tried what was suggested and installed the gfortran build from the gcc package using homebrew which gave me a newer version of gfortran and my problem was fixed!
I had the same problem, but installing gfortran build from the gcc package using homebrew did not help. Instead, I installed the whole gcc using homebrew:
brew install gcc
and that solved the problem.
For those using MacPorts.
# Installed `gcc8` and `gcc_select`
sudo port install gcc_select gcc8
# then to create "gfortran" softlink to "gfortran-mp-8"
sudo port select --set gcc gcc8
# and added to my .profile
export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
I did ls -l /Library/Developer/CommandLineTools/SDKs/ and found that Xcode had installed one SDK for Catalina and one for Big Sur. I changed the soft link for MacOSX.sdk to point to the Catalina version.
Just placed this line at the end of .zshrc:
export LIBRARY_PATH="$LIBRARY_PATH:/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib"
and ran my Fortran code again to compile – success! The issue with -lSystem has been solved in my macOS system.
I had this problem, and I'd tried lots of thing to solve the problem, but only using these "both" commands solved it:
brew reinstall gcc
brew reinstall gfortran
I recently had this
ld: library not found for -lSystem
problem after upgrading Mac OS from v10 to v11 (Big Sur). I am using Xcode 12.3 and I used brew install gcc to install gfortran 10.2.0. I still saw the error after trying brew reinstall gcc. I was able to solve the problem using:
brew install gfortran
but I do not know why this works.

Version of GCC required to build cmake 3.X.Y

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.

GLIBCXX_3.4.9 not found

I have a problem concerning libstdc++.so.
I installed a new version of gcc and tried to compile C++ code. The compiling worked, but when I try to execute the binary (m5.opt is its name) I've got the following error:
build/ALPHA_SE/m5.opt: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by build/ALPHA_SE/m5.opt).
Do I need to replace libstdc++.so? And if so, where can I download the version I want? On the GCC-website they say libstdc++ is a part of gcc now.
Details
GCC:
I had gcc 4.1.2 before, but I downloaded gcc 4.2.4. From the untarred gcc-directory I executed ./configure; make; sudo make install`.
When I tried to use gcc or g++ to compile, it's default version was still 4.1.2. To overcome this I replaced some links:
mv /usr/bin/gcc /usr/bin/gcc_bak
ln -s /usr/local/bin/gcc gcc
mv /usr/bin/g++ /usr/bin/g++_bak
ln -s /usr/local/bin/g++ g++
GLIBC(++) -- libstdc++:
/usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.8
/usr/local/lib/libstdc++.so -> libstdc++.so.6.0.9
/lib/libc.so.6 -> libc-2.5.so -> libc-2.5.so
Linux-version:
uname -a gives:
Linux madmax 2.6.18-128.4.1.el5 #1 SMP Tue Aug 4 12:51:10 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
The problem is that you built your new GCC incorrectly: on Linux you should use
./configure --prefix=/usr
The default installation prefix is /usr/local, which is why make install put gcc and g++ binaries into /usr/local/bin, etc.
What's happening to you now is that you compile and link using the new (symlinked) GCC 4.2.4, but at runtime your program binds to the old /usr/lib64/libstdc++.so.6 (version 6.0.8, instead of required 6.0.9). You can confirm that by running ldd build/ALPHA_SE/m5.opt: you should see that it uses /usr/lib64/libstdc++.so.6.
There are several fixes you could do.
env LD_LIBRARY_PATH=/usr/local/lib64 ldd build/ALPHA_SE/m5.opt
should show you that setting LD_LIBRARY_PATH is sufficient to redirect the binary to correct library, and
LD_LIBRARY_PATH=/usr/local/lib64 build/ALPHA_SE/m5.opt
should just run. You could "bake" this path into m5.opt binary by relinking it with -Wl,-rpath=/usr/local/lib64.
A more permanent solution is to fix the libraries the same way you fixed the binaries:
cd /usr/lib64 && mv libstdc++.so.6 libstdc++.so.6_bak &&
ln -s /usr/local/lib64/libstdc++.so.6 .
An even better solution is to reconfigure the new GCC with --prefix=/usr, and then make all install.
I know this is a very old question, but ...
It's not usually a good idea to replace the system compiler (i.e. the one in /usr) because the entire system will have been built with it and depend on it.
It's usually better to install the new compiler to a separate location and then see the libstdc++ FAQ How do I insure that the dynamically linked library will be found? and Finding Dynamic or Shared Libraries in the manual for how to ensure the correct libstdc++.so is found at runtime.
The other answers here should be fine, but the 'quick and easy' solution if you do happen to have gcc installed to /usr/local/ is to just add the new libs to the LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib64
You can also check the to see if you have the right versions of GLIBC installed using
strings /usr/lib/libstdc++.so.6 | grep GLIBC
strings /usr/local/lib64/libstdc++.so.18 | grep GLIBC
I got this last tip from another forum so credits due where credits due!

Resources