libgcc10 does not seem to install libgcc_ext.10.x dylibs, leaves gcc7 broken

[barracuda156]

Just built libgcc10 10.4.0_3, and it installed literally nothing:

@name libgcc10-10.4.0_3+stdlib_flag
@portname libgcc10
@portepoch 7
@portversion 10.4.0
@portrevision 3
@archs ppc
@portvariant +stdlib_flag
@pkgdep libgcc11-11.3.0_4
opt/local/share/doc/libgcc10/README
@comment MD5:5db79c988f1262e25f04ef5e35e8d306
@comment binary:0
@ignore
+COMMENT
@ignore
+CONTENTS
@ignore
+DESC
@ignore
+PORTFILE
@ignore
+STATE
@cxx_stdlib none
@cxx_stdlib_overridden 0

Portfile has the following:

if { ${os.arch} eq "arm" } {
    set install_dylibs {libgcc_s.2.dylib libgcc_ext.10.4.dylib libgcc_ext.10.5.dylib}
} else {
    set install_dylibs {libgcc_ext.10.4.dylib libgcc_ext.10.5.dylib}
}

And I expected it to install these two dylibs, which are needed by gcc7 to work. 4+ hrs for nothing, gcc7 still broken -_- What is going wrong with that?

16. S. Why do we even need to build multi-hour ports which install nothing but a few lines of readme?

[kencu (Ken)]

what system are you on here?

[barracuda156]

Replying to kencu:

what system are you on here?

I was going through this hell of libgccs more than once: on 10.6.8, 10.6, 10.5.8. (Obviously, I set them to default to libgcc11 or libgcc12 – and yes, everywhere setting is changed accordingly.)

Apparently libgcc9 finally installed two missing dylibs. I still fail to understand why are we required to build every libgccX, when some of them install absolutely nothing. Like, seriously, for what?

16. S. This is especially painful on Leopard with double archs. I can’t think of building 6 (!) libgccs for two archs just to have gcc7 working – which I need literally for a couple of old ports.

[kencu (Ken)]

If and when someone, hopefully not me, actually goes through the project of updating systems 10.4 and 10.5 PPC and Intel to a newer libgcc, probably libgcc12/gcc12 (built with gcc10-bootstrap), I imagine we will arrange things so that none of gcc/libgcc 8,9,10,or 11 are needed.

gcc12 will depend on libgcc12. gcc7 will depend on libgcc7. libgcc7 will depend on libgcc12. Easy. Anything that exists in libgcc12 that is the same, only newer, than what is in libgcc7 will be replaced by the ones in libgcc12.

For the Intel systems from 10.6 up, this developed organically. Each system upgraded to the next one, so it was natural to have all the gccs. But in fact, it would be quite simple, and possibly very beneficial, to just DELETE gcc 8-11 and libgcc 8-11 on all systems, as they are pretty much useless now anyway, and just a maintenance burden for no reason.

[kencu (Ken)]

Likewise, clang 6, 8, 10, and probably 12 and 13 are ripe for deletion as well.

I think clang 5, 7, 9, and 11 are still useful. 9 is a bit questionable. We have to see what bootstrapping looks like with clang11-bootstrap to see just what ones are ripe for deleting.

I can hear the uproar - "Oh NO, we can never do that!" -- but in fact we can, and we should, and Jeremy deleted obsolete clang/llvm versions all the time.

[barracuda156]

Replying to kencu:

If and when someone, hopefully not me, actually goes through the project of updating systems 10.4 and 10.5 PPC and Intel to a newer libgcc, probably libgcc12/gcc12 (built with gcc10-bootstrap), I imagine we will arrange things so that none of gcc/libgcc 8,9,10,or 11 are needed.

gcc12 will depend on libgcc12. gcc7 will depend on libgcc7. libgcc7 will depend on libgcc12. Easy. Anything that exists in libgcc12 that is the same, only newer, than what is in libgcc7 will be replaced by the ones in libgcc12.

For the Intel systems from 10.6 up, this developed organically. Each system upgraded to the next one, so it was natural to have all the gccs. But in fact, it would be quite simple, and possibly very beneficial, to just DELETE gcc 8-11 and libgcc 8-11 on all systems, as they are pretty much useless now anyway, and just a maintenance burden for no reason.

I would keep gcc11 for the time-being. gcc12 has some issues with PPC, as of now. (I mean, I understand we are not deleting anything now, but just for the record.)

[kencu (Ken)]

heh. by the time anyone gets around to doing this, gcc-18 will be out :>