Re: libstdc++.so and mysterious build errors

[Havard Eidnes <he%NetBSD.org@localhost>]

> On Sun 23 Oct 2022 at 16:34:03 +0200, Havard Eidnes wrote:
>> At this point there are at least two ways forwards that i can
>> see:
>>
>> 1) It's an operator error to let old libstdc++.so libraries lay around
>>    (or perhaps specifically libstdc++.so.7*), and I should just remove
>>    those and proceed with life.
>
> It has been my policy for a while (just because of incompatible changes
> in the C++ libraries) that if I have to compile one package with a newer
> gcc, I delete all packages and recompile them with the same gcc. I
> usually rebuild my chroot environment for this occasion to make sure it
> is clean.

Well, yes...  However, that's possibly what one can do on an
individual basis, possibly by manipulating /etc/mk.conf midway
(after the new gcc is installed).  I'm not sure we can translate
that properly into "what should pkgsrc do for a bulk build".

I can of course do as indicated above and remove libstdc++.so
version 6, 7 and 8 from /usr/lib, remove any binary packages
which lists any of those libstdc++.so's as REQUIRED (yes, there
were some), and re-start the entire bulk build.

I am however not entirely convinced that will sort out this
problem properly either.  The reason is that e.g. in the main R
package, ${PREFIX}/lib/R/library/grDevices/libs/cairo.so gets
installed, and via a dynamic dependency via libpangocairo-1.0.so,
libpangoft2-1.0.so, libharfbuzz.so and then libgraphite2.so, the
latter has a dynamic libstdcc++.so.9 dependency which is found in
/usr/lib, since libgraphite2.so is most probably built with the
in-tree c++ compiler.

Once I've removed /usr/lib/libstdc++.so.7, whenever the R module
mentioned earlier is loaded, you can end up with two different major
versions of libstdc++.so dynamically loaded due to the divergent major
shared library version numbering scheme between pkgsrc gcc and in-tree
gcc.  That sounds to me like a recipe for disaster, but what do I know
-- is some trick used so that this isn't really a problem?  Or will
symbols now without warning or error resolve to just one of them?  Or
will you get a dynamic linker error message when the latter is
attempted loaded?

I guess I will find out.

>> 2) Find a way to put the library directory of gcc (in this case
>>    /usr/pkg/gcc10/lib) earlier in the RPATH.  This should preferably
>>    be done in a robust and "pkgsrc-ish" way.
>
> Many years ago I used a FreeBSD system where I had 2 different gcc
> versions installed. They had the same library names, but they were not
> compatible. Of course, one of them was first in the system-wide search
> path. So, programs compiled with the other version were suddenly
> mysteriously broken.  It cost me some time to find out what was going
> on.
>
> This event has brought me to crusade against library search paths.
> System-wide (like in FreeBSD or Linux) they are clearly no good. But
> per-executable (like we have with NetBSD's --rpath) is also not good
> enough. It can still cause the wrong version of a library to be used.
>
> ELF actually supports storing full paths to shared libraries, but our
> tools strip the path if it is given. I did some experiments with
> creating executables with full dependency paths, and with some tricks
> this is already possible. It would however be nicer if the tools didn't
> work against us here.

Indeed.  But I can see problems arising from such a scheme as well, in
that you then either can't easily execute built binaries from inside
the build tree, or forcing externally-maintained packages (what we
have with pkgsrc) to have to implement a "re-link" step before
installation to avoid having installed binaries pointing into the
build directory.

But what do I know, I've not tried following that path myself.

Regards,

- Håvard