[llvm-dev] The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.

[罗勇刚(Yonggang Luo)]

[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)

--

         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

[Brian Cain via llvm-dev]

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".

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--

-Brian

[罗勇刚(Yonggang Luo)]

So CentOS before 6.7 is not an option after all?

Is that possible to use clang on CentOS 6.6 and before?

[Brian Cain via llvm-dev]

On Tue, Jun 28, 2016 at 11:50 AM, 罗勇刚(Yonggang Luo) <luoyo...@gmail.com> wrote:

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

[罗勇刚(Yonggang Luo)]

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

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

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

[罗勇刚(Yonggang Luo)]

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/

gpgcheck=0

enabled=1

```

Installation step:

```

yum clean all

yum list

echo y | yum install devtoolset-4

```

[Brian Cain via llvm-dev]

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.

--

-Brian

[罗勇刚(Yonggang Luo)]

Well, is that possible to include  libstdc++4.7 into llvm?

[Brian Cain via llvm-dev]

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.

--

-Brian

[Craig, Ben via llvm-dev]

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.

_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

[Brian Cain via llvm-dev]

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.

--

-Brian