> On Nov 22, 2024, at 03:18, Chris Jones via macports-dev
> <macports-dev@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
