罗勇刚(Yonggang Luo) via llvm-dev
2016-Jun-29 08:47 UTC
[llvm-dev] The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160629/cbfd6d35/attachment.html>
Brian Cain via llvm-dev
2016-Jun-29 13:28 UTC
[llvm-dev] The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.
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>
Craig, Ben via llvm-dev
2016-Jun-29 13:57 UTC
[llvm-dev] The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.
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. 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>
Brian Cain via llvm-dev
2016-Jun-29 14:31 UTC
[llvm-dev] The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.
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.
On Wed, Jun 29, 2016 at 8:28 AM, Brian Cain <brian.cain at gmail.com>
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>
> 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
>
--
-Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160629/2f689aca/attachment-0001.html>
Apparently Analagous Threads
- The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.
- The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.
- The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.
- The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.
- The clang for centos6 are need GLIBC_2.14, but we only have GLIB 2.12 by default.