10.5 and gcc8 x86-64 ok but ppc bails with dlerror

[Chris Jones]

Hi,

On 05/04/2024 12:30 pm, Ken Cunningham wrote:
> It’s important you understand how the libgcc ports work now, to see how this libgcc chain is set up and the problems it might cause on slower older systems that have no buildbot.
> 
> Go to an Intel system like 10.7, uninstall all ports.
> 
> Disable the buildbot by clearing archive_sites in sources.conf.
> 
> Then try to install gcc7. gcc7 of course requires libgcc7.
> 
> But because libgcc7 depends on libgcc8, libgcc8 will have to be built first.
> 
> But because libgcc8 depends on libgcc9, libgcc9 will have to be built first.
> 
> But because libgcc9 depends on libgcc10, libgcc10 will have to be built first.
> 
> But because libgcc10 depends on libgcc11, libgcc11 will have to be built first.
> 
> But because libgcc11 depends on libgcc12, libgcc12 will have to be built first.
> 
> But because libgcc12 depends on libgcc13,:libgcc13 will have to be built first.
> 
> And libgcc13 is the end of the chain currently…until libgcc14 comes along.

Just to add though, quite a number of those libgccN ports are simply 
stub ports, that do not actually build anything but exist simply to 
define the dependency chain. e.g. libgcc12 is just

Larissa ~/Projects/MacPorts/ports > port contents libgcc12
Port libgcc12 contains:
   /opt/local/share/doc/libgcc12/README

So the *build* chain is no where near as bad as the above might suggest, 
as these stub ports take no time to build or install.

... and, if you are wondering why we have this setup, the basic idea is 
the latest gcc version, for a given OS, provides the default libgcc 
runtime. e.g. libgcc at the moment just depends on libgcc13.

Then, older libgccN versions simple add to the runtime additional 
*older* versions of various libs that that particular gccN needs, and 
which the newer gccN+ do not provide. The reason for doing this is :-

a) the newest gcc vesion always provides the version of a particular 
runtime library
b) all gcc versions that use that runtime share the exact same binary.

This systems works well, and whilst anyone can if they wish propose a 
new one, they will have to demonstrate the reasons why it is better.

It is assumed that *most* users only need a single gcc version, and the 
latest is almost always all they need. So most users only need libgcc13 
and gcc13 (at this time).

cheers Chris

> 
> So that is the chain.
> 
> It is pretty easy to have libgcc7 depend on libgcc13 instead of libgcc8 on older systems, and skip a bunch of this chain. And in base, it’s pretty easy to make gcc7 and gcc13 available compilers on these systems, and not the in between gcc versions.
> 
> It would be messy in both libgccN dependencies and base to skip odd versions of gcc and support even versions. Doable, but messy and confusing for coding and blacklisting. And little point to it.
> 
> And finally, if we are going to update libgcc, we might as well use the current libgcc, rather than the obsolete libgcc8.
> 
> [Barracuda has been suggesting to start up a completely new, separate gcc-ppc port at gcc13 that he would control…but I see no point to that, as it would just be our current gcc13 port anyway with a couple more patches, would break the ”one libstdc++ rule” for all the other gccs in so doing, and make a shambles of gcc compiler selection in base and blacklisting in portfiles.]
> 
>