> On 20 Nov 2024, at 5:56 pm, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > > > > current status then is we have a proposal to restrict available compilers on > systems < 10.6 to > > gcc48, gcc5, gcc6, gcc7, gcc10, and gcc14 > > > 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. > > 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.
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. I also wish you luck in getting the logic right in the portfiles. Finally, remember you will also have to adapt the compilers PG accordingly. 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. Chris > > > > >>> On Nov 20, 2024, at 09:33, Ken Cunningham <ken.cunningham.web...@gmail.com> >>> wrote: >>> >> >> >> >>>> On Nov 20, 2024, at 06:35, Sergio Had <vital....@gmail.com> wrote: >>>> >>> >>> On Nov 20, 2024 at 22:22 +0800, Ken Cunningham >>> <ken.cunningham.web...@gmail.com>, wrote: >>> Any concrete example of something gcc-14 breaks that gcc-13 builds? >>> >>> A lot in fact, but for a reason orthogonal to toolchain as such. >> >> 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. >> >> So that puts that argument to rest. >> >> >>> >>> 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). >>> >>> Other than that no, I believe, and neither gcc7 can build something which >>> gcc14 cannot (and which is actually needed).
