libgcc7 depends on later libgcc8, libgcc9, libgcc10

[barracuda156]

How does this even happen? Why for gcc7/libgcc7 all later libgcc are required now, which likely won’t even build for PPC? (gcc10 onwards do build for PPC, but gcc8/gcc9 may not – earlier they were confirmed to fail.)

10:~ svacchanda$ port deps libgcc7
Full Name: libgcc7 @7.5.0_1
Extract Dependencies: xz
Build Dependencies:   cctools, gmp, isl, ld64, zlib, libiconv, libmpc, mpfr
Library Dependencies: 
Runtime Dependencies: libgcc8
10:~ svacchanda$ port deps libgcc8
Full Name: libgcc8 @8.5.0_1
Extract Dependencies: xz
Build Dependencies:   gcc12
Library Dependencies: libgcc
Runtime Dependencies: libgcc9
10:~ svacchanda$ port deps libgcc9
Full Name: libgcc9 @9.5.0_2
Extract Dependencies: xz
Build Dependencies:   cctools, gmp, isl, ld64, libiconv, libmpc, mpfr, zlib,
                      gcc12
Library Dependencies: libgcc
Runtime Dependencies: libgcc10

[ryandesign (Ryan Carsten Schmidt)]

It has always (for a decade at least?) been the case in MacPorts that all of the gcc ports have been modified to use the latest libgcc libraries. This allows software built with one gcc version to work seamlessly with software built with a different gcc version. However, if the latest libgcc now cannot build on some OS versions, that's a problem.

[barracuda156]

Replying to ryandesign:

It has always (for a decade at least?) been the case in MacPorts that all of the gcc ports have been modified to use the latest libgcc libraries. This allows software built with one gcc version to work seamlessly with software built with a different gcc version. However, if the latest libgcc now cannot build on some OS versions, that's a problem.

Hmm, I see. I do not want to try this on Rosetta now (build several versions of libgcc is just too much), but I will try on Leopard somewhat later. We know for sure that gcc7 and gcc10+ do build and work. What is not known is whether those in between do build now as well.

[kencu (Ken)]

closing this as expected behaviour.

[kencu (Ken)]

libgcc9, for example, would be needed only if gcc9 is supported. If gcc9 is not supported, no need for libgcc9.

ie when/if the jump to libgcc12 happens, 10.4/10.5 could support only gcc7 and then gcc12 on MacPorts, and there is no need for libgcc8-11 to exist.

[barracuda156]

Replying to kencu:

libgcc9, for example, would be needed only if gcc9 is supported. If gcc9 is not supported, no need for libgcc9.

ie when/if the jump to libgcc12 happens, 10.4/10.5 could support only gcc7 and then gcc12 on MacPorts, and there is no need for libgcc8-11 to exist.

For the time-being, how to disable locally unneeded dependencies? Say, I want to build gcc48 needed for some ancient ports. It requires libgcc6, which then wants all later ones. I do not need that (compatibility with new software is not an issue).

10:libbtbb svacchanda$ port deps gcc48
Full Name: gcc48 @4.8.5_6
Extract Dependencies: lbzip2
Library Dependencies: cctools, cloog, gmp, isl14, ld64, zlib, libiconv, libmpc,
                      mpfr
Runtime Dependencies: gcc_select, libgcc6
10:libbtbb svacchanda$ port deps libgcc6
Full Name: libgcc6 @6.5.0_4
Extract Dependencies: xz
Build Dependencies:   cctools, gmp, isl, ld64, zlib, libiconv, libmpc, mpfr
Library Dependencies: 
Runtime Dependencies: libgcc7

What should I do? Just manually remove depends_run for libgcc6? Or instead change to depends_run-append libgcc12, avoiding all in between?

[kencu (Ken)]

looks like you are right…if we do need to skip libgcc 8 to 11 on older systems and just have libgcc7 and then libgcc12, then libgcc7 will have to be rechecked to make sure it provides all the dylibs that are not in libgcc12.

For now, the logic in the libgccN ports does appear to assume all of them are present.

More steps :)