[root@localhost clang+llvm-3.8.0-linux-x86_64-centos6]# cd bin
[root@localhost bin]# ./clang
./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.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 CXXABI_1.3.5' not found (required by ./clang) ./clang: /usr/lib64/libstdc++.so.6: version GLIBCXX_3.4.15’ not found (required by ./clang)
Yes, I believe it was built against centos 6.7. I wanted to build it against an older release but couldn’t quite bootstrap it without newer libstdc++.
Sorry, it would be clearer if I’d have made the package name include “centos6.7”.
So CentOS before 6.7 is not an option after all?
Is that possible to use clang on CentOS 6.6 and before?
Not with these binaries, unless you can update your libc/libstdc++. In the
general sense -- yes, it's possible if you build from source. There's a
couple of potential approaches: build against libc++, build against newer
libstdc++. If you're more adventurous you could also try building with
ellcc. That one requires patches but will yield a statically linked binary.
I built clang trunk/tip a few weeks ago on CentOS 6.0. But I first built
the gcc6 suite, then used it to build clang. I believe clang 3.4.2 is the
latest version that supports the older libstdc++. I ran into challenges
with using clang so I stuck with gcc6. The resulting binaries depend on
the gcc6 libraries so I can't really use this procedure to make a new
official release for centos. If it's helpful I can publish the steps I
used, but really just followed the build instructions.
-Brian
It’s possible to upgrade CentOS’s gcc version from 4.6.1 to gcc 4.8.1 by the following instructions:
wget -O /etc/yum.repos.d/slc6-devtoolset.repo [http://linuxsoft.cern.ch/cern/devtoolset/slc6-devtoolset.repo](http://linuxsoft.cern.ch/cern/devtoolset/slc6-devtoolset.repo)
wget -O /etc/pki/rpm-gpg/RPM-GPG-KEY-cern [http://ftp.scientificlinux.org/linux/scientific/5x/x86_64/RPM-GPG-KEYs/RPM-GPG-KEY-cern](http://ftp.scientificlinux.org/linux/scientific/5x/x86_64/RPM-GPG-KEYs/RPM-GPG-KEY-cern)
yum clean all
yum list
echo y | yum install devtoolset-2
We have no need to upgrade gcc to the newest version(Gcc 6)
the GCC 5 or gcc 4.8.1 is enough to compile clang under centos
Hell, Brian, I found a way to install Gcc 5.3 on CentOS 6 without the need to building it from source. You may try it on CentOS 6.0
That’s makes clang/llvm won’t depends on the newer version of glibc 2.14
The instruction:
vim /etc/yum.repos.d/llvm.repo
The content:
[sclo]
name=SCLO
baseurl=[http://mirror.centos.org/centos/6/sclo/x86_64/rh/](http://mirror.centos.org/centos/6/sclo/x86_64/rh/)
gpgcheck=0
enabled=1
Installation step:
yum clean all
yum list
echo y | yum install devtoolset-4
Sorry if I was unclear, I have no problems building clang against a newer gcc for my own purpose. But it doesn’t make sense to provide a release binary for clang that’s hosted on llvm.org that’s ostensibly for “centos6” when it would really be bound to “centos6 plus the SCLO mirror which has the dependency for a newer libstdc++”.
The glibc 2.14 dependency is a result of the binary being built on a platform new enough to have libstdc++4.7 or newer. You could eliminate it if you could find a CentOS release that has libstdc++4.7 and glibc2.12. But ultimately you’re still stuck with a runtime dependency on libstdc++ shared objects that expect newer GLIBCXX_* symbols.
The newer gcc release is only needed at build-time. Its byproduct/side effect of bringing with it a newer libstdc++ is what creates a runtime dependency.
It’s my position that a CentOS 6.0-6.x release binary for clang newer than 3.4.2 is not possible unless CentOS team backports libstdc++4.7 release to that CentOS release. I’d be happy to learn I’m wrong about that claim BTW.
Well, is that possible to include libstdc++4.7 into llvm?
It is possible to statically link against libstdc++, yes. I don’t quite know all the pieces to the recipe in order to get that to work. It would require changes to the release script in order to get those configuration changes all the way through the third phase build.
I don’t believe any other tarball release does this, so it would at least be an unconventional release.
While it may be possible to jump through some RPATH tricks to use a libstdc++ that is local to clang, you would still run into lots of problems with libclang and friends.
C and C++ library packaging is definitely in the top 10 things I dislike about Linux.
Historically, on Windows, the C and C++ libraries are just regular libraries that aren’t packaged with the OS. They aren’t considered OS components. It’s easy to have multiple installations of the C and C++ library (I think this is / has changed recently?).
On Linux libstdc++ is usually packaged with the OS. System administrators would not like it if a random package upgraded libstdc++ for the entire system. The flat symbol namespace on Linux makes it difficult to provide multiple versions without breaking significant use cases.
Yonggang,
What’s your use case(s) for clang? If you don’t need the {A,T,UB}San features, you might get much of what you want from ellcc (http://ellcc.org/releases/). ellcc is primarily used for cross-target development. But there’s no reason you can’t use it to target x86_64 linux too.