IRC channel 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

IRC channel logs

2021-08-05.log