gcc compilers to be supported by Macports, especially on older MacOS systems

Sergio Had vital.had at gmail.com
Wed Nov 20 14:43:00 UTC 2024


Serge
On Nov 20, 2024 at 22:28 +0800, Ken Cunningham <ken.cunningham.webuse at gmail.com>, wrote:
> once the default moves to gcc-14, gcc7 has to still work. You cannot have only one compiler available, that is too risky.
>
> right now, gcc7 needs libgcc7 and that means libgcc 8,9,10,11,12 and 13 need to build, which they probably don’t, and even if they do, is crazy.
>
> so this is what needs to be hopefully resolved here.

Ken, you say “probably”, which means you didn’t try, but I have built all of them on several PowerPC systems (10.5–10.6).

I agree with you that this arrangement is suboptimal and it always have been, but the situation does not differ for 10.6 x86, and somehow no one is bothered much about that. (Perhaps no one really needs those old compilers?)

However, after my ticket on Trac situation improved a bit, and one does not need to build every libgcc* in sequence anymore. At least those which installed nothing, are not built now, they just make an entry in MacPorts registry. Prior to this being fixed is was insane indeed.
>
> > On Nov 20, 2024, at 06:23, Sergio Had <vital.had at gmail.com> wrote:
> >
> > As I keep stressing, there is no need to throw away old gccs right now. A move to gcc14 simply means that it will take longer to build gcc5, if at all someone ever needs that.
> >
> > Given that modern gcc is strictly required now, it is a tiny cost.
> >
> > After all, this is exactly how things have been on 10.6+, and nobody dies :)
> >
> > Serge
> > On Nov 20, 2024 at 22:04 +0800, Ken Cunningham <ken.cunningham.webuse at gmail.com>, wrote:
> > >
> > >
> > > > On Nov 20, 2024, at 05:49, Sergio Had <vital.had at gmail.com> wrote:
> > > >
> > > > As a daily user of PowerPC systems for past 2+ years, I would gladly remove all non-Apple gcc versions besides:
> > > >
> > > > a) the current release (gcc14 at the moment);
> > > > b) gcc10-bootstrap (to build initial toolchain);
> > > > c) gcc7-bootstrap, if 10.4 actually needs it.
> > > > d) gcc-devel, to test the current upstream (what I have as gcc-powerpc in my fork).
> > > >
> > > > All the rest belong to the history.
> > >
> > > That would in practice leave older systems with only gcc-14 to use as a compiler to build ports, as the bootstrap ports cannot be used for building final ports (abi issues)
> > >
> > > That is a very very shallow bench that I could not support.
> > >
> > >
> > >
> > > >
> > > > There is a problem with TFF/Aquafox, which are at the moment (until Palemoon fixes are complete) the best browsers on PowerPC, but they do not need a modern libgcc either. Arguably gcc48-bootstrap may be introduced as a temporary solution.
> > > >
> > > > If the main gcc is installed without version postfix, that removes a need to bother about revbumping R, MLton and OCaml which bake in specific compiler value.
> > > >
> > > > This is probably what I am going to do locally anyway, eventually.
> > > >
> > > > Having said that, the concern that something gets broken with a move to gcc14 is unjustified: it simply takes longer to build an archaic version of gcc if someone needs it. But why would one? I literally never had to use gcc5 or gcc7 ever since Kirill made gcc10-bootstrap which allowed to switch to gcc11.
> > > > Across all MacPorts tree perhaps 1–2 ports require gcc7 presently. Those should be fixed or, if the code is hopelessly outdated, possibly dropped.
> > > >
> > > > gcc7 has no good use. It is obsolete, not maintained either by upstream or by MacPorts (nothing gets backported), not being able to build a lot of ports now, not supporting modern C++, broken on ppc64 etc. Forcing people use it as a main compiler is a disservice to them and unnecessary hassle for maintainers, since we get breakage reports which otherwise would not be there.
> > > >
> > > > To sum up:
> > > > Right now old systems should be moved to gcc14, without modifying current arrangement. These two are independent issues.
> > > > Upon consensus on libgcc is reached, that is to be addressed accordingly.
> > > >
> > > >
> > > > Serge
> > > > On Nov 20, 2024 at 21:18 +0800, Ken Cunningham <ken.cunningham.webuse at gmail.com>, wrote:
> > > > > Hi Riccardo, yes need your input!
> > > > >
> > > > > Reasoning for list I offerred:
> > > > >
> > > > > apple-gcc42 stays, of course. unique and needed on 10.4
> > > > > gcc4.8 … tenfourfox
> > > > > gcc5 … for the java compiler used in pdftoolkit on older systems
> > > > > gcc7 … current default compiler used for 5 years now on 10.4/5, well known, but staring to be a few things it can’t build, hence the pressure to upgrade
> > > > > gcc10 .. last one that builds without c++11 … little used, but we need a fallback about here, so this is a guess as to a good fallback
> > > > > gcc14 … current, has been used for the past year or so as the default compiler on ppc (by a small number of people TBH)
> > > > >
> > > > > If this is to be useful and worth doing, the list needs to be shortish.
> > > > >
> > > > > Another could be added later I suppose, but would be some pain.
> > > > >
> > > > > All others would be dropped, (except the bootstraps) as anything they built would potentially ABI breaking due to mismatched libs.
> > > > >
> > > > >
> > > > > > On Nov 20, 2024, at 02:16, Riccardo Mottola <riccardo.mottola at libero.it> wrote:
> > > > > >
> > > > > > Hi Ken,
> > > > > >
> > > > > > I think in the past, I asked for something similar.
> > > > > >
> > > > > > Two questions:
> > > > > > 1) if a user wants a compiler beyond the "golden list"? will you remove the ports alltogether or will it just mean for him more compilation because it builds another libgcc?
> > > > > > 2) can we start with a minimal list and then "tweak" things if we discover some software not building and add e.g. one or two versions later?
> > > > > >
> > > > > > Ken Cunningham wrote:
> > > > > > > The list of uniquely useful gcc compilers might be as short as:
> > > > > > >
> > > > > > > gcc-4.8, gcc5, gcc7, gcc10, and gcc-14.
> > > > > > >
> > > > > > > All those already build on the older systems, and are at least a manageable list of versions to maintain.
> > > > > > >
> > > > > > > Could we ask for thoughts and possible get consensus that the list of gcc compilers supported by MacPorts be shortened to a list such as that?
> > > > > >
> > > > > > Making this list is I think a trade-off between a newer compiler breaking old code and capability of also compiling newer software.
> > > > > >
> > > > > > My favorite is usually:
> > > > > >
> > > > > > gcc4.8 (very good for old stuff... very stable everywhere and never found the need to use gcc 4.2 instad of gcc 4.8 except to stick with apple versions)
> > > > > > gcc 6.5 : best "classic" compiler on 10.5/10.6, reliable, definitely to be included in list
> > > > > > gcc 8 : first "modern" compiler
> > > > > >
> > > > > > and then... gcc12 or 13 just because I used them long time and gcc14 is new, undecdided about which to choose
> > > > > >
> > > > > > I think gcc5 can be dropped.. either 4.8 or 6.5 should do
> > > > > >
> > > > > > gcc7 has been for a year the newest compiler on 10.5 for me, but can it be replaced by 6.5 or gcc8?
> > > > > >
> > > > > > gcc10: could we try do drop it and have latest?
> > > > > > gcc14 - I have used it very little on MacOS - but I do on linux and it is very finky...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20241120/c5c51a48/attachment-0001.htm>


More information about the macports-dev mailing list