libstdc++.so and mysterious build errors

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

Hi,

while chasing down build problems in pkgsrc, I find that a number
of packages, perhaps primarily in the R universe fail to build
(actually, most of them do their building in the "install" phase,
for whatever reason...).  The pattern of the error is:

Error: package or namespace load failed for 'RandomFieldsUtils' in dyn.load(file, DLLpath = DLLpath, ...):
 unable to load shared object '/usr/pkgsrc/math/R-RandomFieldsUtils/work/.destdir/usr/pkg/lib/R/library/00LOCK-RandomFieldsUtils/00new/RandomFieldsUtils/libs/RandomFieldsUtils.so':
  /usr/lib/libstdc++.so.7: version CXXABI_1.3 required by /usr/pkgsrc/math/R-RandomFieldsUtils/work/.destdir/usr/pkg/lib/R/library/00LOCK-RandomFieldsUtils/00new/RandomFieldsUtils/libs/RandomFieldsUtils.so not defined

So...  Looking at the chroot I'm building in, it has been
upgraded a number of times (not re-installed), so it has a fair
collection of libstdc++ versions in it's /usr/lib:

# ls -ltr libstdc++*
-r--r--r--  1 root  wheel  1251742 Aug  1  2008 libstdc++.so.6.0
lrwxr-xr-x  1 root  wheel       16 Aug  8  2008 libstdc++.so.6 -> libstdc++.so.6.0
-r--r--r--  1 root  wheel  1419297 Dec 27  2016 libstdc++.so.7.1
lrwxr-xr-x  1 root  wheel       16 Dec 27  2016 libstdc++.so.7 -> libstdc++.so.7.1
-r--r--r--  1 root  wheel  2600788 Feb  3  2019 libstdc++_pic.a
-r--r--r--  1 root  wheel  1469200 Feb  3  2019 libstdc++.so.8.1
lrwxr-xr-x  1 root  wheel       16 Feb  3  2019 libstdc++.so.8 -> libstdc++.so.8.1
-r--r--r--  1 root  wheel  4516902 Aug 28 19:02 libstdc++.a
-r--r--r--  1 root  wheel  5076648 Aug 28 19:02 libstdc++_p.a
-r--r--r--  1 root  wheel  2665732 Aug 29 00:52 libstdc++.so.9.0
lrwxr-xr-x  1 root  wheel       16 Aug 29 00:52 libstdc++.so.9 -> libstdc++.so.9.0
lrwxr-xr-x  1 root  wheel       16 Aug 29 00:52 libstdc++.so -> libstdc++.so.9.0
#

What's characteristic for the R packages is that many of them
build with gfortran, and in my case, building this on what's
going to be 10.0, gcc 10.4.0 from pkgsrc gets installed.  And it
appears that gcc 10.4.0 has a different versioning scheme for its
libstdc++.so.  From one of my other -current-running hosts:

$ cd /usr/pkg/gcc10/lib
$ ls -lL libstdc++.so*
-rwxr-xr-x  1 root  wheel  17431568 Jul 25 05:43 libstdc++.so*
-rwxr-xr-x  1 root  wheel  17431568 Jul 25 05:43 libstdc++.so.7*
-rwxr-xr-x  1 root  wheel  17431568 Jul 25 05:43 libstdc++.so.7.28*
-rw-r--r--  1 root  wheel      2397 Jul 25 05:43 libstdc++.so.7.28-gdb.py
$ 

and the linker invocation (from the build log) for the
RandomFiledsUtils.so shared object looks like this:

c++ -std=gnu++14 -shared -Wl,-R/usr/pkg/lib/R/lib -L/usr/pkg/lib/R/lib -Wl,-zrelro -L/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -pthread -L/usr/X11R7/lib -Wl,-R/usr/X11R7/lib -o RandomFieldsUtils.so RFoptions.o bckslvmodified.o brdomain.o cholmodified.o kleinkram.o linear.o maths.o options.o own.o scalar.o solve.o sort.o spamown.o utils.o win_linux_aux.o zzz.o -llapack -lblas -lblas -fopenmp -L/usr/pkg/gcc10/lib/gcc/powerpc--netbsd/10.4.0 -L/usr/pkg/gcc10/lib -Wl,-R/usr/pkg/gcc10//lib/. -Wl,-R/usr/pkg/gcc10/lib/. -lgfortran -lm -lpthread -L/usr/pkg/gcc10/lib/gcc/powerpc--netbsd/10.4.0 -L/usr/pkg/gcc10/lib -Wl,-R/usr/pkg/gcc10//lib/. -Wl,-R/usr/pkg/gcc10/lib/. -lgfortran -lm -lpthread -Wl,-R/usr/pkg/lib/R/lib -L/usr/pkg/lib/R/lib -lR

I think that means that /usr/lib ends up before /usr/pkg/gcc10/lib in
the RPATH for that shared object, and consequently the wrong
libstdc++.so.7 gets picked up, and the check for the CXXABI_1.3
triggers as above, and the build + install fails.

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.

   A counterpoint to this solution is that this would be the natural
   result of a normal system upgrade -- we typically leave old major
   versjons of libraries and their symlinks remain, so that any
   programs still linked against those major versions can continue to
   work.

   And the root cause of this problem, that gcc in pkgsrc has a
   different versioning scheme than our in-tree gcc for libstdc++
   remains and will probably come back to bite us later.

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.

   Arguably this would be the more robust of the two fixes, but
   guidance sought as to how to go about doing that.

Comments?

Regards,

- Håvard