[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