Recently, when installing the new version of Clang (Clang 3.4/3.5) to the compilation environment CentOS 6.5, although the GCC 4.9.1 was installed, it was compiled (refer to the Clang official homepage http://clang.llvm.org/get_ Started.html steps, running the clang configure script in the standalone build directory, still gives the "C compiler cannot create executables" prompt to view log information, There are several errors found inside:
Clang:/lib64/libc.so.6:version ' glibc_2.15 ' not found (required by clang)
Clang:/lib64/libc.so.6:version ' glibc_2.14 ' not found (required by clang)
Clang:/usr/lib64/libstdc++.so.6:version ' glibcxx_3.4.18 ' not found (required by clang)
Clang:/usr/lib64/libstdc++.so.6:version ' glibcxx_3.4.15 ' not found (required by clang)
Here is the two system version of the library version is too low, one is about C + + library libstdc++, one is about the C system Base runtime glibc, the former is better to do, the latter is very basic, a general version of the CentOS will specify a glibc, you can go to upgrade, However, the stability of the CentOS itself can be compromised.
1. We begin to solve the problem of glibcxx, C + + library, first look at the error message in the Lib file information.
$ strings/usr/lib64/libstdc++.so.6 | grep GLIBC
Here is the information for qualifying (grep) glibc libraries in the output information of the print libstdc++.so.6
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
glibc_2.3
glibc_2.2.5
glibc_2.3.2
glibcxx_force_new
glibcxx_debug_ Message_length
Again
$ll /usr/lib64/libstdc++.so.6
lrwxrwxrwx 1 root Sep 06:21/usr/lib64/libstdc++.so.6->/usr/lib64/libstdc++.so.6.0.13
That is, the system used to have a 6.0.13 version, it is really old, then we have a new version. We installed the GCC 4.9.1, should have already installed a new version of the libstdc++, if not, you can go to the next online.
First find in this machine:
Find/-name libstdc++.so.6*
We found that GCC installed the/libstdc++.so.6.0.20 under the/usr/local/lib64, but did not change the libstdc++.so.6 link point.
Then we manually update the soft connection (also byte point to the file under/usr/local, do not copy, look at the pigeon's file management habits)
$ cp/usr/local/lib64/libstdc++.so.6.0.20/usr/lib64
$ rm-rf/usr/lib64/libstdc++.so.6
$ ln-s/usr/lib64/ Libstdc++.so.6.0.20/usr/lib64/libstdc++.so.6
$ strings/usr/lib64/libstdc++.so.6 | grep GLIBC
And then the result:
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
glibc_2.3
glibc_2.2.5
glibc_2.3.2 Force_new
Glibcxx_debug_message_length
Library update complete. We've already supported glibcxx_3.4.20.
Now compile again, the problem of glibcxx is not.
2. About C Basic Run-time library glibc, because be careful, so I write the next blog:
"Linux/centos upgrade C basic Run-time Library CLIBC considerations (when you want to solve the glibc_2.x can not find a compilation problem)"