<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Oct 4, 2017 2:31 PM, "Rui Ueyama via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="quoted-text">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><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></div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I don't necessarily agree with the last point.</div><div dir="auto">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.</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">--</div><div dir="auto">Davide</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div class="elided-text"><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="m_-3025106230746079029HOEnZb"><font color="#888888">
</font></span></p><span class="m_-3025106230746079029HOEnZb"><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="m_-3025106230746079029h5">
<br>
<div class="m_-3025106230746079029m_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_-3025106230746079029m_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_-3025106230746079029m_7536378356922522841mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="m_-3025106230746079029m_7536378356922522841moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_-3025106230746079029m_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></div><br></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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></div></div>