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

[Chris Jones]

On 21/11/2024 3:34 pm, Chris Jones via macports-dev wrote:
> 
>> 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).

So, I just took a look at what is actually installed by the binary 
tarballs for OSX10.6 (the oldest I can check via 
https://packages.macports.org/) got gcc versions 7 through to 13

Of these the only versions that install any dylibs (and thus are not in 
practise just stub ports) are

libgcc7
libgcc9

thats it !

of the others, I think these are currently not correctly configured as 
stub ports and thus build is actually run, but in the end nothing is 
done with it

libgcc8
libgcc10
libgcc11


these are already properly configured as stub ports

libgcc12
libgcc13

So the very first thing that someone should do is fix these three ports

libgcc8
libgcc10
libgcc11

to avoid running the build needlessly.

Once done, the number of (real) builds you will actually need with the 
current dep tree will be much much reduced.

Chris

p.s. Obviously I have the caveat I do not know what happens on <10.6 
machines. Someone with access to these should run

 > port contents libgccN

for each of them and report what is actually there· If all you see is 
something like

pcmf ~/Downloads/gcc > tar -jxvf libgcc8-8.5.0_1.darwin_10.x86_64.tbz2
./
./+COMMENT
./+CONTENTS
./+DESC
./+PORTFILE
./+STATE
./opt/
./opt/local/
./opt/local/share/
./opt/local/share/doc/
./opt/local/share/doc/libgcc8/
./opt/local/share/doc/libgcc8/README

then the port is just a stub port and the build should be disabled to 
avoid needlessly running it.


> 
> Chris