IRC channel logs

2021-08-05.log

back to list of logs

<rekado_>one of the biggest drawbacks to using Guix is ABI incompatibility
<rekado_>that’s not really Guix’s fault, but it means that you can’t supplement a Guix environment with third-party packages.
<rekado_>I wonder if there’s anything that can be done about this.
<rekado_>we already have a workaround to mixing Guix packages with “install.packages” in R: just isolate the environment and provide the compiler toolchain and libraries from Guix.
<rekado_>but is there any chance of loading a pre-built library in a Guix-built application?
<rekado_>patchelf has been used successfully to “bend” existing libraries into shape
<rekado_>I wonder if there’s a hack we can come up with to let Guix packages coexist with third-party packages (e.g. binaries installed via pip or conda).
<rekado_>if we could do that we would remove the biggest practical barrier to using Guix.
<rekado_>I’ve seen this so often: “I need this one package, but I can only get it via Conda” — “well, you can’t mix Guix things with Conda things” — “too bad, I’ll stay with Conda then”
<drakonis>there are a few ways to achieve it
<drakonis>rather, the main way to do it, is to provide a way to coerce guix into providing a fhs environment
<drakonis>this is not for the foreign distro though
<rekado_>would that actually help?
<rekado_>it would help in finding libraries at conventional locations
<rekado_>but even when library locations are not an issue we cannot load libraries that have been linked with a different version of glibc (for example)
<rekado_>one of the common problems here is to use R from Guix with R packages that have been linked with system libraries.
<rekado_>the system’s libc is older than the one from Guix; glibc is forward-compatible within reason, but generally this fails to work
<drakonis>hmm
<drakonis>there is an elaborate solution to the problem
<drakonis>i just don't think it might be the cleanest one
<rekado_>oh, I’m not looking for something clean :)
<rekado_>I just want *any* solution :)
<drakonis>okay so
<rekado_>I’m not sure I understand the problem, to be honest
<rekado_>the error message usually looks backwards to me
<rekado_>like /usr/lib/libc.so appears in the output, but also some /gnu/store/….so
<drakonis>the biggest hack here is to hook up something that does patchelf on the fly
<rekado_>yes, I had a similar idea
<drakonis>to redirect any calls to the store when needed
<drakonis>collabora wrote something like this, its called libcapsule
<rekado_>but I don’t really know exactly how we want to resolve libs
<drakonis>its also the same principle behind libglvnd in which it will look for available libgl implementations
<drakonis>bedrock linux once tried to do something similar, but deemed it a bit complicated because linking libraries across distributions is complicated
<drakonis>cross distribution builds
<drakonis>also relevant
<drakonis>there was a nix adjacent project for writing a daemon that redirects shell scripts to the store
<drakonis>reshelved? i think?
<drakonis> https://github.com/abathur/resholved
<drakonis>honestly, i feel like this might be the domain of either a scheme based shell with scripts to take care of this on the fly
<drakonis>or a daemon for foreign systems
<drakonis>i'd rather have this on a guile shell to automatically handle these tasks
<rekado_>wow, libcapsule is wild
<drakonis>it is, yeah.
<rekado_>IIUC it requires configuration for each library that should be supported
<drakonis>it does what libglvnd does but for anything you want
<drakonis>i'd kill for a guile based shell for doing all of those things instead
<drakonis>i think resholve might be closer to what you want?
<drakonis>at least the idea it tries to achieve
<drakonis>the other thing that could be done is to have an environment variable to look up for libraries built outside of the auspices of guix
<drakonis>but then that opens up another can of worms
<drakonis> https://bedrocklinux.org/0.7/feature-compatibility.html
<drakonis>this encapsulates any cross distribution interop questions btw
<drakonis>as bedrock's entire reason d'être is to mix up distros
<drakonis>raison d'être
<dstolfa>4/
<dstolfa>oops, that was meant to be /4 :)
<drakonis>ha
<drakonis>anyways, it would be a valuable development, since playing with software unmanaged by guix can be inconvenient sometimes