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

[Ken Cunningham]

> On Nov 22, 2024, at 03:18, Chris Jones via macports-dev <macports-dev at lists.macports.org> wrote:
> 
> 
>> So the very first thing that someone should do is fix these three ports
>> libgcc8
>> libgcc10
>> libgcc11
> 
> See
> 
> https://github.com/macports/macports-ports/commit/eea28397c811c477a04407cbe3c105c76efd9219
> 
> https://github.com/macports/macports-ports/commit/06e249f837f36a877ea5dc0dd67d7b0caf964c40
> 
> ( Note I was wrong about libgcc8, it is already properly configured as a stub port )
> 
> With that, considering gcc version 7 through to 14, the only real builds, so removing all the stubs are
> 
> gccN
> libgcc14
> libgcc9
> libgcc7
> 
> So for any GCC version a user might request between 10 and 14, they will only need to build two ports, one runtime (libgcc14, shared for all of them) and the specific gcc version requested. Given how we split the compiler from the runtime, this is as good as it can get.
> 
> For gcc9, you will need to build gcc9, libgcc9 and libgcc14
> 
> For gcc7, you will need to build gcc7, libgcc7, libgcc9 and libgcc14
> 
> So, as far as I see it the best way you can minimize the number of gcc versions you need to build on these ancient systems, is to migrate as many builds as you can to use gcc10 or gcc14 (the two newest ones in the list you sent around), as then you are already in the best case scenario (two builds). I see no compelling reason to change the dependency tree in the libgccN versions.
> 
> Chris


Thanks for sorting out libgccN better. Now that so many are just stubs, that’s easier, certainly, and changes the approach favourably.

K