GNU bug report logs - #60200
Incompatibilities between gcc-toolchain and R packages

Previous Next

To reply to this bug, email your comments to 60200 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lars-Dominik Braun <lars <at> 6xq.net>
To: bug-guix <at> gnu.org
Subject: Incompatibilities between gcc-toolchain and R packages
Date: Mon, 19 Dec 2022 13:00:02 +0100

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 <at> 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 <at> 10 the default and rename gcc-toolchain <at> 12 to
  gcc-toolchain-next <at> 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

Message #8 received at 60200 <at> debbugs.gnu.org (full text, mbox):

From: zimoun <zimon.toutoune <at> gmail.com>
To: Lars-Dominik Braun <lars <at> 6xq.net>, 60200 <at> debbugs.gnu.org
Subject: Re: bug#60200: Incompatibilities between gcc-toolchain and R packages
Date: Tue, 20 Dec 2022 00:32:26 +0100

Hi Lars,

On Mon, 19 Dec 2022 at 13:00, Lars-Dominik Braun <lars <at> 6xq.net> wrote:
>     $ 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 <at> 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:

[...]

> Possible solutions:
>
> - Make gcc-toolchain <at> 10 the default and rename gcc-toolchain <at> 12 to
>   gcc-toolchain-next <at> 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.

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

The default GCC toolchain for compiling is provided by the package
gcc-toolchain <at> 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:

--8<---------------cut here---------------start------------->8---
$ guix show gcc <at> 6
guix show: error: gcc <at> 6: package not found

$ guix show gcc <at> 7
name: gcc
version: 7.5.0
outputs:
+ lib: shared libraries
+ debug: debug information
+ out: everything else
systems: x86_64-linux i686-linux
dependencies: gmp <at> 6.2.1 isl <at> 0.23 libelf <at> 0.8.13 libstdc++-headers <at> 10.3.0 mpc <at> 1.2.1 mpfr <at> 4.1.0 perl <at> 5.34.0 texinfo <at> 6.7 zlib <at> 1.2.11
location: gnu/packages/gcc.scm:601:2
homepage: https://gcc.gnu.org/
license: GPL 3+
synopsis: GNU Compiler Collection  
description: GCC is the GNU Compiler Collection.  It provides compiler front-ends for several languages, including C, C++, Objective-C, Fortran, Ada, and
+ Go.  It also includes runtime support libraries for these languages.
--8<---------------cut here---------------end--------------->8---

It is because the ’properties’ field of gcc <at> 7 is rewritten,

--8<---------------cut here---------------start------------->8---
(define-public gcc-7
  (package
    (inherit gcc-6)
    (version "7.5.0")
[...]
    (properties
     `((compiler-cpu-architectures
        ("aarch64" ,@%gcc-7.5-aarch64-micro-architectures)
        ("armhf" ,@%gcc-7.5-armhf-micro-architectures)
        ("x86_64" ,@%gcc-7.5-x86_64-micro-architectures))))))
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
$ guix repl
GNU Guile 3.0.8
Copyright (C) 1995-2021 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> ,use(gnu packages gcc)
scheme@(guix-user)> (package-properties gcc-6)
$1 = ((hidden? . #t) (gcc-libc . #f))
scheme@(guix-user)> (package-properties gcc-7)
$2 = ((compiler-cpu-architectures ("aarch64" "armv8-a" "armv8.1-a" "armv8.2-a" "armv8.3-a") ("armhf" "armv7" "armv7-a" "armv7-m" "armv7-r" "armv7e-m" "armv7ve" "armv8-a" "armv8-a+crc" "armv8.1-a" "armv8.1-a+crc" "armv8-m.base"
"armv8-m.main" "armv8-m.main+dsp" "iwmmxt" "iwmmxt2") ("x86_64" "core2" "nehalem" "westmere" "sandybridge" "ivybridge" "haswell" "broadwell" "skylake" "bonnell" "silvermont" "knl" "skylake-avx512" "k8" "k8-sse3" "barcelona" "bdver1"
"bdver2" "bdver3" "bdver4" "znver1" "btver1" "btver2" "geode")))
scheme@(guix-user)>
--8<---------------cut here---------------end--------------->8---

Because the intent of,

--8<---------------cut here---------------start------------->8---
(define-public gcc-toolchain-aka-gcc
  ;; It's natural for users to try "guix install gcc".  This package
  ;; automatically "redirects" them to 'gcc-toolchain'.
  (deprecated-package "gcc" gcc-toolchain-10))
--8<---------------cut here---------------end--------------->8---

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 <at> 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 <at> 11 and gcc-toolchain <at> 12 as gcc-toolchain-next <at> 11 and
gcc-toolchain-next <at> 12.  Which would be consistent with the rest.

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


Cheers,
simon

Message #11 received at 60200 <at> debbugs.gnu.org (full text, mbox):

From: Lars-Dominik Braun <lars <at> 6xq.net>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 60200 <at> debbugs.gnu.org
Subject: Re: bug#60200: Incompatibilities between gcc-toolchain and R packages
Date: Wed, 21 Dec 2022 10:24:03 +0100

[Message part 1 (text/plain, inline)]

Hi Simon,

> 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.
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

[default-gcc-toolchain.patch (text/plain, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.