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

[Philip Reames via llvm-dev]

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 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
> 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/7241bdb1/attachment.html>