<p dir="ltr">Stable releases don't upgrade the toolchain because the whole system is guaranteed to be stable under a single combination of the compiler, libraries, tools, headers, secondary libraries, etc. </p>
<p dir="ltr">Validation of a new toolchain means releasing a whole new distro, with old packages, but they're busy validating new releases, too. </p>
<p dir="ltr">The gcc abi 5 issue is on recent event that you could have a read to understand what kinds of problems can happen. </p>
<p dir="ltr">Windows just duplicates all libraries and each app is independent. You can use different compilers, but you end up with a big list of dlls all over the place, and compatibility is never guaranteed. </p>
<p dir="ltr">How Steam has hacked Linux support is a good example of Windows style on Linux, and the quality you get is a good reason not to follow that path. </p>
<p dir="ltr">They're just different models, with different constraints. If we were a distro, trying to change the status quo would be fun. We don't have that bandwidth, so we just do what everyone else is doing. :-)</p>
<p dir="ltr">Cheers, <br>
Renato </p>
<div class="gmail_extra"><br><div class="gmail_quote">On 12 Oct 2016 11:40 p.m., "Pete Cooper" <<a href="mailto:peter_cooper@apple.com">peter_cooper@apple.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Oct 12, 2016, at 3:33 PM, Renato Golin <<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>> wrote:</div><br class="m_-5378413995584835832Apple-interchange-newline"><div><p dir="ltr">Hi Peter, </p><p dir="ltr">We don't ship proper toolchains for distros, we ship toys that worked on one developer's machine, and that includes our binaries as well. </p></div></blockquote>Ok, thats fair. Having never actually downloaded one, I didn’t know the state of it.</div><div><br></div><div>Out of interest, are newer toolchains available from apt-get and other similar package managers? The only part of supporting linux/BSD in this way I question is that we end up stuck with whatever shipped with the OS, not what may be available via their package managers. If the available packages are also old GCC versions then fair enough, but I just want to understand the ecosystem.<br><blockquote type="cite"><div><p dir="ltr">Distro validation is a huge deal, especially toolchain, and we're in no way equipped to even try to do a bad job at that. </p><p dir="ltr">Unix is a different world than that of Windows and Mac, and it makes no sense to force the same requirements, either way. </p></div></blockquote>I guess I already alluded to this, but if a package is available in the same way that a new Xcode/MSVC is available, then i’m not sure why we should treat it differently.<br><blockquote type="cite"><div><p dir="ltr">I don't opine on msvc or xcode topics or design decisions because I don't know enough to have any reasonable opinion, and I most certainly won't try to make them more like Unix. </p></div></blockquote>You should. We need plenty of voices to make sure we make the best decisions we can. Incidentally, i’ve built GCC in a past life on the PlayStation 2 Linux environment. I’m somewhat aware of the pain, although that was quite a time ago.</div><div><blockquote type="cite"><div><p dir="ltr">These things are what they are for good reasons and I think we should just leave it at that. </p><p dir="ltr">Cheers, <br>
Renato </p><p dir="ltr">PS: I don't mean disrespect either, but we have this discussion every time someone mentions upgrading gcc. </p></div></blockquote>None taken.<br><blockquote type="cite"><div><p dir="ltr">Maybe we should write some documentation to avoid repeating the same arguments. :-)</p><div><br></div></div></blockquote>SGTM. I’m willing to admit my almost complete ignorance in all things linux/BSD, so to have it written down somewhere and avoid the next person like me asking would be good.</div><div><br></div><div>Cheers,</div><div>Pete<br><blockquote type="cite"><div><div><br></div>
<div class="gmail_extra"><br><div class="gmail_quote">On 12 Oct 2016 11:19 p.m., "Pete Cooper via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Oct 11, 2016, at 1:46 PM, Michael Kuperstein via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="m_-5378413995584835832m_6500180152756160265Apple-interchange-newline"><div><div dir="ltr">To the best of my understanding - because we want to be able to bootstrap clang with the system compiler that ships with various linux and BSD distributions.<div>Windows has no equivalent concept.</div></div></div></blockquote>I mean no offense to linux/BSD developers, but should we have a discussion (in another thread perhaps) about whether its reasonable to treat them specially in this regard?</div><div><br></div><div>Both macOS and Windows developers need to download compilers separately to be LLVM developers. Why shouldn’t linux/BSD developers? </div><div><br></div><div>Given that we ship prebuilt binaries for many distros, it seems like its easy to get a new enough compiler. This way we won’t be faced with the problem of old GCCs holding us back in future.</div><div><br></div><div>Pete<br><blockquote type="cite"><div><div dir="ltr"><div><div><br></div><div>(This is probably not a good enough reason to keep GCC 4.7 support, but it apparently is for GCC 4.8).</div><div><br></div><div>Michael</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 11, 2016 at 10:28 AM, Martin J. O'Riordan 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">Why is it more important to be backward compatible with ancient versions of GCC than relatively more recent versions of Visual Studio? We are removing support for VS2013 because of defects in that product, yet GCC v4.7.x is more ancient than VS2013, so why should the answer be any different?<br>
<br>
Devil's Advocate,<br>
<br>
MartinO<br>
<div class="m_-5378413995584835832m_6500180152756160265HOEnZb"><div class="m_-5378413995584835832m_6500180152756160265h5"><br>
-----Original Message-----<br>
From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists<wbr>.llvm.org</a>] On Behalf Of Renato Golin via llvm-dev<br>
Sent: 11 October 2016 18:01<br>
To: Sylvain Bertrand <<a href="mailto:sylvain.bertrand@gmail.com" target="_blank">sylvain.bertrand@gmail.com</a>><br>
Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>; Peter Collingbourne <<a href="mailto:pcc@google.com" target="_blank">pcc@google.com</a>><br>
Subject: Re: [llvm-dev] unable to compile llvm with gcc 4.7.4<br>
<br>
On 11 October 2016 at 17:35, <<a href="mailto:sylvain.bertrand@gmail.com" target="_blank">sylvain.bertrand@gmail.com</a>> wrote:<br>
> Those bots should have been the first to be set up. Hope you can fix this soon.<br>
<br>
We had 4.7 bots for a long time, but migrations happen, and we probably (separately) didn't expect to be the last 4.7 ones. This was a coordination problem.<br>
<br>
Now, there are talks to upgrade the GCC version from 4.7, but we can't do 4.9 because many stable distributions still 4.8, but we can do 4.8, which has enough buildbots (and will for the long term).<br>
<br>
I'm not saying this is a "fix" for your problem, but your problem would happen any time soon when we move the GCC version up anyway.<br>
<br>
Can you upgrade to 4.8?<br>
<br>
cheers,<br>
--renato<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>
______________________________<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>
</div></div></blockquote></div><br></div>
______________________________<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" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br></div></blockquote></div><br></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></div>
</div></blockquote></div><br></div></blockquote></div></div>