Incompatibilities between gcc-toolchain and R packages

Hi,

I ran into issues with the package r-brms. Take the following reproducer as an example:

$ guix shell r-brms r make sed gcc-toolchain bash -C --no-cwd --share=/tmp

$ R

> library(brms)

> fit1 <- brm(count ~ zAge + zBase * Trt + (1|patient), data = epilepsy, family = poisson())

Compiling Stan program...

Error in dyn.load(libLFile) :

unable to load shared object '/tmp/RtmpKqzbYg/file3245e787c.so':

/gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by /tmp/RtmpKqzbYg/file3245e787c.so)

Error in sink(type = "output") : invalid connection

The same code works well with gcc-toolchain@10 instead of gcc-toolchain

(@12, which is the default). As we can see the generated shared library

above depends on GCC 12, 10 and GFortran 10 at the same time:

$ ldd /tmp/RtmpKqzbYg/file3245e787c.so | grep -e gcc -e fortran

libstdc++.so.6 => /gnu/store/4zvswpr2h3b7dvqpvjcdam8vfhyjrmgl-gcc-12.2.0-lib/lib/libstdc++.so.6 (0x00007f69bd9fc000)

libgcc_s.so.1 => /gnu/store/4zvswpr2h3b7dvqpvjcdam8vfhyjrmgl-gcc-12.2.0-lib/lib/libgcc_s.so.1 (0x00007f69bd898000)

libgfortran.so.5 => /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libgfortran.so.5 (0x00007f69bd3e6000)

libquadmath.so.0 => /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libquadmath.so.0 (0x00007f69bd39b000)

libgomp.so.1 => /gnu/store/094bbaq6glba86h1d4cj16xhdi6fk2jl-gcc-10.3.0-lib/lib/libgomp.so.1 (0x00007f69bccf9000)

The command used to link that .so is revealed by strace to be (filenames

are random and may differ between runs):

["g++", "-std=gnu++14", "-shared", "-L/gnu/store/145dmr8drw3yzrdhzbsksi05p599hrs6-r-minimal-4.2.2/lib/R/lib", "-L/usr/local/lib", "-o", "file3373276d0.so", "file3373276d0.o", "/gnu/store/5rdg6sv1nrg1ikqxcykvdh9g4yd2xjvy-r-rstan-2.21.7/site-library/rstan/lib//libStanServices.a", "-L/gnu/store/y7rvp47mz3hcnpvnqsx42qz5yvs10pnl-r-stanheaders-2.21.0-7/site-library/StanHeaders/lib/", "-lStanHeaders", "-L/gnu/store/01lhjrrkvrnsjd8xh4ssdn3bgxc422jl-r-rcppparallel-5.1.5/site-library/RcppParallel/lib/", "-ltbb", "-L/gnu/store/145dmr8drw3yzrdhzbsksi05p599hrs6-r-minimal-4.2.2/lib/R/lib", "-lR"]

So it links against libStanServices.a, libStanHeaders(.a), libtbb(.so) and

libR(.so) of which only libR has a reference to gfortran:

$ ldd /gnu/store/145dmr8drw3yzrdhzbsksi05p599hrs6-r-minimal-4.2.2/lib/R/lib/libR.so | grep -i fortran

libgfortran.so.5 => /gnu/store/vqhamsanmlm8v6f90a635zc6gmhwlphp-gfortran-10.3.0-lib/lib/libgfortran.so.5 (0x00007f5be49db000)

That means every software linking against R is also incompatible with

the current default gcc-toolchain (when using the command line or

specifications; different story when writing package recipes).

Possible solutions:

- Make gcc-toolchain@10 the default and rename gcc-toolchain@12 to

gcc-toolchain-next@12, like we do for Haskell and (sometimes) Python.

- Update, both, the default GCC and GFortran to version 12.

- Explicitly depend on the correct gcc-toolchain in packages that need

a compiler.

Cheers,

Lars

Hi Lars,

On Mon, 19 Dec 2022 at 13:00, Lars-Dominik Braun <lars@6xq.net> wrote:

[...]

It depends on what you are naming default. :-)

The default GCC toolchain for compiling is provided by the package

gcc-toolchain@10.

Without any specification about the version, if a package name is

defined at several versions, then the command-line uses the higher

version of this package. To avoid the kind of confusing error as you

are observing, usually, the suffix ’-next’ is applied to the package

name for higher versions. For instance, python-numpy-next.

To add a data point to the confusion, consider the package ’gcc’ instead

of ’gcc-toolchain’. As noticed earlier [1], there is a bug. Consider:

It is because the ’properties’ field of gcc@7 is rewritten,

and thus, it looses ’hidden’, as shown here:

Because the intent of,

is to return the default GCC toolchain when typing ’gcc’ at the command

line. And error for any other version than @10.

1: https://yhetil.org/guix/87h6yz46wp.fsf@gmail.com

Update the default GCC toolchain from 10 to 12 is a core-updates change

and a (almost) full world rebuild. When the issue you are describing is

an issue about an inconsistency with the command-line.

From my point of view, an option would to rename the packages

gcc-toolchain@11 and gcc-toolchain@12 as gcc-toolchain-next@11 and

gcc-toolchain-next@12. Which would be consistent with the rest.

And also fix the bug with the package ’gcc’. :-)

Cheers,

simon

Hi Simon,

minor nit-pick: Not the command-line, but everything that uses

specifications. So manifests via SPECIFICATIONS->MANIFEST are also

affected, see:

(use-modules (gnu packages) (guix profiles))

(manifest-entries (specifications->manifest '("gcc-toolchain")))

$2 = (#<<manifest-entry> name: "gcc-toolchain" version: "12.2.0" …)

The -next suffix has the obvious disadvantage that specifications may

become invalid as we move -next to the “regular” package. So maybe

marking packages “default” like the attached patch does could improve

the current situation. Not just for gcc, but also Haskell and Python

come to mind.

Cheers,

Lars