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

[Rui Ueyama via llvm-dev]

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 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171004/d5175a21/attachment.html>