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

[Ken Cunningham]

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.

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.]