[llvm-dev] Minimal glibc version supported by LLVM build

Wed Oct 4 15:48:57 PDT 2017

On Wed, Oct 4, 2017 at 3:17 PM, Davide Italiano <davide.italiano at gmail.com>
wrote:

>
>
> On Oct 4, 2017 2:31 PM, "Rui Ueyama via llvm-dev" <llvm-dev at lists.llvm.org>
> wrote:
>
> On Wed, Oct 4, 2017 at 2:19 PM, Philip Reames <listmail at philipreames.com>
> wrote:
>
>> Our build system is setup to deliberately use a very old environment.
>> We've found that's one of the most reliable easy ways to ensure we don't
>> accidentally introduce a dependency on a newer system library than
>> intended.  This lets us ship prebuilt binaries which run on a wide spectrum
>> of systems.  We're going to chat internally and check to see if we can roll
>> this forward a bit, but supporting an older glibc is definitely going to be
>> somewhat we want.  Exactly *how* old might be flexible, but I have to check.
>>
>> Rui, let me turn your question around on you.  What version of glibc
>> would you like to be our minimum?  And why?  Is there a good reason to move
>> this forward?
>>
> I don't have a clear answer to your question, and I don't think I'm a
> person who can set a standard, but maybe, 11 years is a bit too old. I
> don't think we want to intentionally break it, and if it can be supported
> by adding a few lines to CMakeFiles, we probably should. However, IMO, this
> should be done by best-effort basis. I don't think we need to immediately
> revert a patch if broke a 11 year old system.
>
>
> I don't necessarily agree with the last point.
> I think a policy would help here, and it should be based on the number of
> annoyances supporting an old version cause. This is akin to what we did
> for, e.g. VS 2013. If supporting a old version doesn't allow the project to
> reasonably move forward, we should consider an upgrade. FWIW, in this case
> I don't think the feature introduced is worth the bump, but your mileage
> may vary.
> I'd like to add that "11 years old system" means nothing. In fact, I think
> we should aim supporting even older systems whenever possible.
>

I agree that we should support old systems whenever possible. There's no
reason to intentionally break it, and it is generally good if it works on a
large number of systems including old ones.

But speaking of this instance, I feel like reverting a patch as well as
other related patches immediately when it's found it broke a very old
system was a bit too hasty. If we want to keep everything work with an old
system all the time, we should set up a buildbot with an old version of an
operating system. Otherwise, I think a more time should be given to
developers to discuss and fix an issue in the main repository.

> Thanks,
>
> --
> Davide
>
>
> I think we need to establish and document a minimum supported version
>> here.  I'm open to debating what that version should be, but the current
>> lack of clarity is clearly problematic.
>>
>> Philip
>>
>> p.s. Sorry about the confusion earlier about CentOS.  I'd misunderstood
>> an statement in internal conversation and repeated the information without
>> checking.  While true that the build failed on a CentOS 6.4 system, it was
>> being built against a non-default (older) glibc.
>>
>> p.p.s. This brought up the point internally that we really should have a
>> public build bot for the configuration we care about.  I need to talk that
>> over internally, but this seems like something we can make happen.
>>
>> On 10/04/2017 12:38 PM, Rui Ueyama via llvm-dev wrote:
>>
>> Serguei,
>>
>> glibc 2.5 was released 11 years ago, so I wonder what operating system
>> you are using now.
>>
>> On Wed, Oct 4, 2017 at 12:08 AM, Serguei Katkov via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hi All,
>>>
>>>
>>>
>>> The landed patch https://reviews.llvm.org/D38481 introduced the usage
>>> of CPU_COUNT defined in glibc sched.h header.
>>>
>>> I failed to find this symbol in sched.h of glibc version 2.5-24, so
>>> compilation just fails.
>>>
>>> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp:
>>> In function ‘unsigned int llvm::hardware_concurrency()’:
>>>
>>> /home/dolphin/merge-from-upstream-area/ws/pristine/lib/Support/Threading.cpp:80:26:
>>> error: ‘CPU_COUNT’ was not declared in this scope
>>>
>>>      return CPU_COUNT(&Set);
>>>
>>>                           ^
>>>
>>>
>>>
>>> It is buildable with newest version of glibc.
>>>
>>> I tried to find a requirements for glibc version in LLVM documentation
>>> but failed.
>>>
>>> So I wonder whether there is such requirement or not.
>>>
>>> Could anyone point me to this documentation?
>>>
>>>
>>>
>>> I'm trying to understand whether patch is wrong which relies on
>>> availability of library but does not check the symbol itself or this
>>> version of glibc is not supported.
>>>
>>>
>>>
>>> Thank you,
>>>
>>> Serguei.
>>>
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171004/f62ea3bf/attachment.html>