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

Craig, Ben via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 29 06:57:27 PDT 2016

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 

On 6/29/2016 8:28 AM, Brian Cain via llvm-dev wrote:
> 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.
> On Wed, Jun 29, 2016 at 3:47 AM, 罗勇刚(Yonggang Luo) 
> <luoyonggang at gmail.com <mailto:luoyonggang at gmail.com>> wrote:
>     Well, is that possible to include  libstdc++4.7 into llvm?
>     On Wed, Jun 29, 2016 at 2:26 AM, Brian Cain <brian.cain at gmail.com
>     <mailto:brian.cain at gmail.com>> wrote:
>         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 <http://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.
>         On Tue, Jun 28, 2016 at 1:13 PM, 罗勇刚(Yonggang Luo)
>         <luoyonggang at gmail.com <mailto:luoyonggang at gmail.com>> wrote:
>             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
>             ```
>             On Wed, Jun 29, 2016 at 1:15 AM, Brian Cain
>             <brian.cain at gmail.com <mailto:brian.cain at gmail.com>> wrote:
>                 On Tue, Jun 28, 2016 at 11:50 AM, 罗勇刚(Yonggang Luo)
>                 <luoyonggang at gmail.com <mailto:luoyonggang at 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
>             -- 
>                    此致
>>             罗勇刚
>             Yours
>                 sincerely,
>             Yonggang Luo
>         -- 
>         -Brian
>     -- 
>              此致
>>     罗勇刚
>     Yours
>         sincerely,
>     Yonggang Luo
> -- 
> -Brian
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160629/b3d89f73/attachment.html>

More information about the llvm-dev mailing list