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

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

On Wed, Jun 29, 2016 at 3:47 AM, 罗勇刚(Yonggang Luo) <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> 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 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
>> > 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>
>>> wrote:
>>>
>>>> On Tue, Jun 28, 2016 at 11:50 AM, 罗勇刚(Yonggang Luo) <
>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160629/9637fc83/attachment.html>