Re: Issue with 'guix shell' for Guile projects on non-Guix distros
Hi Ludo, On Thu, Mar 16, 2023 at 11:55 AM Ludovic Courtès wrote: > > Hello, > > "Thompson, David" skribis: > > > Here's the context: Someone wants to build guile-goblins from a Git > > checkout using their non-Guix, FHS distro. However, they happen to > > have Guile 3 installed to /usr via the host distro's package manager. > > I was going to suggest running ‘guix shell --check …’, which can detect > a class of problems on non-Guix distros, but that’s not the problem > here. > > > They install Guix, run 'guix shell', then './bootstrap.sh' and that > > all works fine. Then they run './configure' and this happens: > > [...] > > > The most important line above is: > > > > checking for guile-3.0... /usr/bin/guile-3.0 > > > > Guile's guile.m4 code checks for a 'guile-3.0' executable *before* > > checking for a 'guile' executable. Guix's Guile package only provides > > 'guile', but the host distro provides 'guile-3.0'. Unfortunately, the > > build environment ends up as a mix of host distro and Guix things > > which eventually proves fatal to the build. > > I’ve not encountered this before. > > My suggestion would be to recommend running ‘guix shell -CP’ as this > addresses problems of that sort once and for all. I do that, even on > Guix System: it’s pretty reassuring to know that your dev environment is > isolated from the rest. > > Alternatively, ‘guix shell --pure’ would also address that because then > ‘configure’ wouldn’t look for programs under /usr/bin. It’s less robust > though. I should have mentioned that we did get a working environment by using --container, but it required explaining why the tools from the host, like git, were no longer available and how those would have to be used outside of the Guix shell. Same with --pure, only with additional complications because of a .bashrc that was referring to lesspipe and other things that were no longer available. I tend to prefer plain 'guix shell' because, usually, it does the right thing without additional surprises for someone who is unfamiliar with Guix. Each method has its downsides, not sure what to recommend going forward. - Dave
Re: Issue with 'guix shell' for Guile projects on non-Guix distros
Hello, "Thompson, David" skribis: > Here's the context: Someone wants to build guile-goblins from a Git > checkout using their non-Guix, FHS distro. However, they happen to > have Guile 3 installed to /usr via the host distro's package manager. I was going to suggest running ‘guix shell --check …’, which can detect a class of problems on non-Guix distros, but that’s not the problem here. > They install Guix, run 'guix shell', then './bootstrap.sh' and that > all works fine. Then they run './configure' and this happens: [...] > The most important line above is: > > checking for guile-3.0... /usr/bin/guile-3.0 > > Guile's guile.m4 code checks for a 'guile-3.0' executable *before* > checking for a 'guile' executable. Guix's Guile package only provides > 'guile', but the host distro provides 'guile-3.0'. Unfortunately, the > build environment ends up as a mix of host distro and Guix things > which eventually proves fatal to the build. I’ve not encountered this before. My suggestion would be to recommend running ‘guix shell -CP’ as this addresses problems of that sort once and for all. I do that, even on Guix System: it’s pretty reassuring to know that your dev environment is isolated from the rest. Alternatively, ‘guix shell --pure’ would also address that because then ‘configure’ wouldn’t look for programs under /usr/bin. It’s less robust though. HTH, Ludo’.
Issue with 'guix shell' for Guile projects on non-Guix distros
Hey everyone, At Spritely we've run into a situation where 'guix shell' doesn't "just work" for setting up a development environment and we're wondering about the best way to fix it. We're experiencing this issue with our guile-goblins project currently, but this appears to be a more general problem that likely affects most projects that use Guile's guile.m4 autoconf code. Here's the context: Someone wants to build guile-goblins from a Git checkout using their non-Guix, FHS distro. However, they happen to have Guile 3 installed to /usr via the host distro's package manager. They install Guix, run 'guix shell', then './bootstrap.sh' and that all works fine. Then they run './configure' and this happens: $ ./configure checking for a BSD-compatible install... /gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking for pkg-config... /gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/pkg-config checking pkg-config is at least version 0.9.0... yes configure: checking for guile 3.0 configure: found guile 3.0 checking for guile-3.0... /usr/bin/guile-3.0 checking for Guile version >= 3.0... 3.0.7 checking for guild-3.0... /gnu/store/w7ag4ilvb6inp9vc71dxzmdkz738m37w-profile/bin/guild checking for guile-config-3.0... no checking for Guile site directory... /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/share/guile/site/3.0 checking for Guile site-ccache directory using pkgconfig... /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/lib/guile/3.0/site-ccache checking for Guile extensions directory... /gnu/store/cnfsv9ywaacyafkqdqsv2ry8f01yr7a9-guile-3.0.7/lib/guile/3.0/extensions checking if (fibers) is available... no configure: error: required guile module not found: (fibers) The most important line above is: checking for guile-3.0... /usr/bin/guile-3.0 Guile's guile.m4 code checks for a 'guile-3.0' executable *before* checking for a 'guile' executable. Guix's Guile package only provides 'guile', but the host distro provides 'guile-3.0'. Unfortunately, the build environment ends up as a mix of host distro and Guix things which eventually proves fatal to the build. As a workaround, I am considering adding a package to our manifest.scm file that symlinks 'guile' to 'guile-3.0', 'guild' to 'guild-3.0', etc. so that they take priority over the host executables. Internally, we are tracking this issue here: https://gitlab.com/spritely/guile-goblins/-/issues/84 Has anyone encountered something like this before? If so, how did you deal with it? Should something be changed in Guix itself to avoid this issue altogether? - Dave
