Re: pre-C++11 compilers

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sat, Jul 01, 2017 at 02:27:46PM +0000, coypu%sdf.org@localhost wrote:
> libstdc++ is mostly backwards compatible, but nowhere near forward
> compatible. If we ever use more than one libstdc++, we want to use the
> newest for all dependencies.

Correct, modulo the issue with GCC 5.1+ and abi_tag. So using GCC 4.9
for everything should normally work, but going over to 5.1 and later can
be a problem again.

> If it's a leaf C++ package, it's easy - just use the newer GCC to build
> it too, and by using g++ it will pull in the newer libstdc++ always.
> Most packages that needed it were probably like this. Also, leaf
> packages being broken is easy to miss.

The canonical non-leaf example that worked correctly was lang/llvm and
lang/clang. lang/libLLVM is a mixed bag, using the C interface you can
create problems and the whole MesaLib situation has been covered
already.

> If it's a C package, it becomes problematic. using a newer GCC isn't
> sufficient to guarantee that a newer libstdc++ will be picked, and it
> depends on the link order.

That and also libgcc_s itself, but the latter is less likely to be seen
in practise.

> Now we have packages like icu and MesaLib requiring it, which have very
> many dependencies, so the chance of encountering the broken scenario is
> likely.

Dependees, not dependencies. The other direction :)

> NetBSD specifically has an extra complication because it major bumped
> libstdc++ in base but pkgsrc GCC still creates the old soname.
> I think libstdc++.so.7 and libstdc++.so.6 appear as different libraries?
> That should probably be fixed.

While it might be nice to patch lang/gcc* to use the same major version,
it doesn't change that much.

> I should restore the change to make MesaLib not use the dri option for
> older compilers, but luckily it is also controllable by options.

As default behavior, that's not the worst idea.

Joerg