[llvm-dev] Minimal glibc version supported by LLVM build
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Thu Oct 5 09:31:40 PDT 2017
On 10/04/2017 03:48 PM, Rui Ueyama wrote:
> On Wed, Oct 4, 2017 at 3:17 PM, Davide Italiano
> <davide.italiano at gmail.com <mailto:davide.italiano at gmail.com>> wrote:
>
>
>
> On Oct 4, 2017 2:31 PM, "Rui Ueyama via llvm-dev"
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
> On Wed, Oct 4, 2017 at 2:19 PM, Philip Reames
> <listmail at philipreames.com <mailto: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.
In retrospect, I think I agree. We were probably too quick to revert
here. When I asked Daniel to do so, I was working with the flawed
assumption that this was relevant for any REHL 6 based distro, but I
should have checked that more thoroughly before we acted.
> 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
>> <mailto:llvm-dev at lists.llvm.org>> wrote:
>>
>> Hi All,
>>
>> The landed patch https://reviews.llvm.org/D38481
>> <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 <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> <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/20171005/78de1084/attachment.html>
More information about the llvm-dev
mailing list