Package: guix;
Reported by: Lars-Dominik Braun <lars <at> 6xq.net>
Date: Mon, 19 Dec 2022 12:01:02 UTC
Severity: normal
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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.