tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index] and mysterious build errors


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/':
  /usr/lib/ version CXXABI_1.3 required by /usr/pkgsrc/math/R-RandomFieldsUtils/work/.destdir/usr/pkg/lib/R/library/00LOCK-RandomFieldsUtils/00new/RandomFieldsUtils/libs/ 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
lrwxr-xr-x  1 root  wheel       16 Aug  8  2008 ->
-r--r--r--  1 root  wheel  1419297 Dec 27  2016
lrwxr-xr-x  1 root  wheel       16 Dec 27  2016 ->
-r--r--r--  1 root  wheel  2600788 Feb  3  2019 libstdc++_pic.a
-r--r--r--  1 root  wheel  1469200 Feb  3  2019
lrwxr-xr-x  1 root  wheel       16 Feb  3  2019 ->
-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
lrwxr-xr-x  1 root  wheel       16 Aug 29 00:52 ->
lrwxr-xr-x  1 root  wheel       16 Aug 29 00:52 ->

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  From one of my other -current-running hosts:

$ cd /usr/pkg/gcc10/lib
$ ls -lL*
-rwxr-xr-x  1 root  wheel  17431568 Jul 25 05:43*
-rwxr-xr-x  1 root  wheel  17431568 Jul 25 05:43*
-rwxr-xr-x  1 root  wheel  17431568 Jul 25 05:43*
-rw-r--r--  1 root  wheel      2397 Jul 25 05:43

and the linker invocation (from the build log) for the 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 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 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

1) It's an operator error to let old libraries lay around
   (or perhaps specifically*), 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

   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.



- Håvard

Home | Main Index | Thread Index | Old Index