<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Hi,</div><div dir="ltr"><br><blockquote type="cite">On 20 Nov 2024, at 10:00 pm, Ken Cunningham <ken.cunningham.webuse@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">Glad everyone gets to weigh in. If we can get a consensus to do this, we'll try to do it as smartly as possible.<div><br></div><div>Any gcc compilers that come "free" -- ie don't contribute anything in libgcc and so are just "no-ops" -- we can consider keeping those. However, they still might get pulled in needlessly if they exist, according to the compilers dependency rules.</div><div><br></div><div>For example, as Riccardo said, if gcc10 can build it, but gcc13 exists, then gcc13 might get pulled in unnecessarily to build it.</div></div></blockquote><div><br></div>If gcc13 is available and can be used to successfully build a port, then why would you want to use gcc10 ?<div><br></div><div>The logic in the compilers PG etc. as to which compilers are picked to use is to always favour the most recent that is available (and not blacklisted). This logic will minimise deps needed as gcc13 only needs libgcc13 and libgcc14 whereas gcc 10 would need libgcc(10-12) in addition. So i think this is the right logic.</div><div><br></div><div>Chris</div><div><br><blockquote type="cite"><div dir="ltr"><div><br></div><div>And every one of these is a huge build burden.</div><div><br></div><div>Strangely enough, the really ancient ones (gcc48, gcc5, and gcc6) are not really much of a problem as they all depend on gcc7, which will be needed for a long time (until everything is shown to build without it, really, which could take years).</div><div><br></div><div><br></div><div>Ken</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><div><div>On 2024-11-20, at 1:32 PM, Chris Jones wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">One other comment.</div><div dir="ltr"><br></div><div dir="ltr">When talking about the dependency tree we have with the gcc builds, it’s important to remember this is only for the runtime ports, libgccN. The tree is not there for the actual compiler ports themselves. So gccN does not depend on gcc N+1 and so on.</div><div dir="ltr"><br></div><div dir="ltr">The other important thing to remember is not every libgcc build actually builds anything. A number of them are just stub ports that build nothing at all, and thus take no time to build, and only exist to set up the dependency tree.</div><div dir="ltr"><br></div><div dir="ltr">Libgcc13 and libgcc12 fall into this category for example. Building neither of these takes any time so lets take the example of a user requesting gcc 12. The gcc builds they will need for this are</div><div dir="ltr"><br></div><div dir="ltr">gcc12</div><div dir="ltr">Libgcc12</div><div dir="ltr">Libgcc13</div><div dir="ltr">Libgcc14</div><div dir="ltr"><br></div><div dir="ltr">Of those, only the first and last are actually builds. </div><div dir="ltr"><br></div><div dir="ltr">Compare that to what is needed for say the latest gcc</div><div dir="ltr"><br></div><div dir="ltr">Gcc14</div><div dir="ltr">Libgcc14</div><div dir="ltr"><br></div><div dir="ltr">So the number of actual builds that take any meaningful time is the same, just 2</div><div dir="ltr"><br></div><div dir="ltr">This is in part why i object to removing perfectly functional compiler options from users, as the gains are really not there in reality.</div><div dir="ltr"><br></div><div dir="ltr">Sure, lets discuss dropping some really old compilers, anything less than say gcc10 I think we could discuss removing, but for me the argument to remove the newer ones just does not really exist.</div><div dir="ltr"><br></div><div dir="ltr">Chris</div><div dir="ltr"><br><blockquote type="cite">On 20 Nov 2024, at 9:00 pm, Chris Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk">jonesc@hep.phy.cam.ac.uk</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On 20 Nov 2024, at 5:56 pm, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr">current status then is we have a proposal to restrict available compilers on systems < 10.6 to </div><div dir="ltr"><br></div><div dir="ltr">gcc48, gcc5, gcc6, gcc7, gcc10, and gcc14</div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">This list seems workably short. I’ll leave this sit for a while while we see if anyone has more to say about it or thinks of some reason why something should be adjusted.</div><div dir="ltr"><br></div><div dir="ltr">I would continue to prefer the list be macports-wide, even if that means gcc13 instead of gcc10, or if one more gcc needs to be added. But we won’t bring down progress on the older systems arguing about that if that will be a sticking point.</div></div></blockquote><div><br></div>Personally, I will object to turning off gcc 11 through 13 on newer systems for no good reason. If you wish to disable these on < 10.6 thats your choice, I have no real interest myself in anything that old, but I will insist you do this via a check on the darwin version such that newer OSes are not effected.<div><br></div><div>I also wish you luck in getting the logic right in the portfiles.</div><div><br></div><div>Finally, remember you will also have to adapt the compilers PG accordingly.<br><div><br></div><div>I am open to removing some very old compilers entirely, in fact most of these are effectively already disabled on up to date OSes via the platforms setting anyway.</div><div><br></div><div>Chris<br><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Nov 20, 2024, at 09:33, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Nov 20, 2024, at 06:35, Sergio Had <<a href="mailto:vital.had@gmail.com">vital.had@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">
<title></title>
<div name="messageReplySection">
<div dir="auto">On Nov 20, 2024 at 22:22 +0800, Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>>, wrote:</div>
<blockquote style="border-left-color: rgb(26, 188, 156); margin: 5px; padding-left: 10px; border-left-width: thin; border-left-style: solid;">Any concrete example of something gcc-14 breaks that gcc-13 builds?</blockquote>
<div dir="auto"><br>
A lot in fact, but for a reason orthogonal to toolchain as such.<br></div></div></div></blockquote><div><br></div><div>Well, if there is “a lot” that won’t build with gcc-14, that certainly cements the idea it had better not be the only working compiler in macports on older systems.</div><div><br></div><div>So that puts that argument to rest.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div name="messageReplySection"><div dir="auto">
<br>
gcc14 became stricter with warnings vs errors, so either all affected ports’ code has to be fixed (in practice this usually translates into “fixed by who builds those with gcc”, i.e. typically myself), which requires hours and hours, or folks with “veto rights” should not prevent at least fixing these ports by adding a `-Wno-error=` flag (which is done in numerous ports for clangs, but for gcc it every time turns into an argument).<br>
<br>
Other than that no, I believe, and neither gcc7 can build something which gcc14 cannot (and which is actually needed).</div>
</div>
</div></blockquote></div></blockquote></div></blockquote></div></div></div></div></blockquote></div></blockquote></div><br></div></div></blockquote></div></body></html>