bug#60200: Incompatibilities between gcc-toolchain and R packages

[zimoun]

Hi Lars,

On Mon, 19 Dec 2022 at 13:00, Lars-Dominik Braun <lars@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@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@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.

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:

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

$ guix show gcc@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@6.2.1 isl@0.23 libelf@0.8.13 libstdc++-headers@10.3.0 
mpc@1.2.1 mpfr@4.1.0 perl@5.34.0 texinfo@6.7 zlib@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@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@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