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

Chris Jones jonesc at hep.phy.cam.ac.uk
Thu Nov 21 15:34:26 UTC 2024


> likewise, if I look at the compilers PG
> 
> https://github.com/macports/macports-ports/blob/master/_resources/ 
> port1.0/group/compilers-1.0.tcl
> 
> the list there is also already restricted to
> 
>   lappend gcc_versions 5 6 7 8 9
> 
> if I am parsing things correctly.
> 
> So, where exactly are the gcc compilers 10 to 14 entering the game 
> currently for builds on <10.6 ?
> 


I guess we are back to the point about the issue being not really with 
the gcc-N ports, but the libgcc-N ports as it is there where the 
dependency tree currently lives.

So taking gcc10 as an example, to install this from scratch you need

gcc10
libgcc10
libgcc11
libgcc12
libgcc13
libgcc14

and removing those ports that are just stub ports so building takes no time

gcc10
libgcc10
libgcc11
libgcc14

so compared to the minimum, which would be 2 builds (one gccN and one 
libgccM build) we are taking 4 builds instead of 2.

So yes, its twice the builds you in theory would need in the best case 
scenario. Whilst not ideal, this is (for me) hardly the nightmare 
scenario people seem to be making it out to be.

( Also note, I suspect a number of those builds *could* be made stub 
ports, but currently they are not, either because the port is badly 
written or by giving up on some optional functionalities, like sanitizer 
libs)

My problem with what you are proposing is changing how the dependencies 
between the various libgccN ports is currently configured, to be 
different on <10.6 to the newer OSes, is likely going to be waay more 
messy than I think you are currently anticipating. To my eye, trying to 
reduce as many libgccN ports down to basic stub ports that become 
trivial to install is the better way forward).

Chris


More information about the macports-dev mailing list