<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 4, 2017 at 2:19 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
<p>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? </p></div></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><p>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. </p><p><span class="HOEnZb"><font color="#888888">
</font></span></p><span class="HOEnZb"><font color="#888888">
<p>Philip</p>
</font></span><p>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. <br>
</p>
<p>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. <br>
</p><div><div class="h5">
<br>
<div class="m_7536378356922522841moz-cite-prefix">On 10/04/2017 12:38 PM, Rui Ueyama via
llvm-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Serguei,
<div><br>
</div>
<div>glibc 2.5 was released 11 years ago, so I wonder what
operating system you are using now.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Oct 4, 2017 at 12:08 AM,
Serguei Katkov via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="#0563C1" vlink="#954F72" lang="EN-US">
<div class="m_7536378356922522841m_-5366148437303026918WordSection1">
<p class="MsoNormal">Hi All,</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">The landed patch <a href="https://reviews.llvm.org/D38481" target="_blank">https://reviews.llvm.org/D3848<wbr>1</a>
introduced the usage of CPU_COUNT defined in glibc
sched.h header.</p>
<p class="MsoNormal">I failed to find this symbol in
sched.h of glibc version 2.5-24, so compilation just
fails.</p>
<p class="MsoNormal"><span>/home/dolphin/merge-from-upstr<wbr>eam-area/ws/pristine/lib/Suppo<wbr>rt/Threading.cpp:
In function ‘unsigned int
llvm::hardware_concurrency()’:</span></p>
<p class="MsoNormal"><span>/home/dolphin/merge-from-upstr<wbr>eam-area/ws/pristine/lib/Suppo<wbr>rt/Threading.cpp:80:26:
error: ‘CPU_COUNT’ was not declared in this scope</span></p>
<p class="MsoNormal"><span> return
CPU_COUNT(&Set);</span></p>
<p class="MsoNormal"><span> ^</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">It is buildable with newest version
of glibc. </p>
<p class="MsoNormal">I tried to find a requirements for
glibc version in LLVM documentation but failed.</p>
<p class="MsoNormal">So I wonder whether there is such
requirement or not.</p>
<p class="MsoNormal">Could anyone point me to this
documentation?</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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.</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thank you,</p>
<p class="MsoNormal">Serguei.</p>
<p class="MsoNormal"><span lang="RU"> </span></p>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="m_7536378356922522841mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="m_7536378356922522841moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_7536378356922522841moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>