To reduce ABI inconsistencies, Jeremy and others set up a system whereby we have a single set of libgcc libraries that are used by all the gcc versions supported on MacPorts. The latest version of a given gcc library is used by all the gcc compilers.
So gcc5, for example, requires libgcc5, which then depends on libgcc6, which depends on libgcc7, and so on up to the current libgcc (currently libgcc14 for the moment). That requires building many versions of libgcc to get access to gcc5, however. On older systems in particular, where there is no buildbot, this brings on an onerous cascade of libgcc versions that need to be built to support anything beyond the most current gcc compiler. This is not only a build-time burden, but a maintenance burden, as these compilers often require tweaking to build properly on these older systems. This has been a major factor that prevented older systems from being updated to a newer gcc/libgcc version for a while now. It would be considerably less onerous if MacPorts as a whole used a subset of gcc / libgcc compilers. If that is not considered acceptable, perhaps it might be accepted to have a subset of gcc compilers available just on the older systems. The list of uniquely useful gcc compilers might be as short as: gcc-4.8, gcc5, gcc7, gcc10, and gcc-14. All those already build on the older systems, and are at least a manageable list of versions to maintain. Could we ask for thoughts and possible get consensus that the list of gcc compilers supported by MacPorts be shortened to a list such as that? It would be simpler if that was a MacPorts-wide setup. That way, system-version workarounds in all the ports that list available gcc compilers would be avoided. Ken
