Wiktor Żelazny <[email protected]> writes:
> [[PGP Signed Part:Undecided]] > On Mon, Jan 17, 2022 at 12:57:54PM +0100, Ricardo Wurmus wrote: >> >> jsmith via <[email protected]> writes: >> >> > ERROR: In procedure dlopen: >> > In procedure dlopen: file >> > "/gnu/store/35apwp40n8rnlqyxf7hagwr250nw754w-guile-dbi-2.1.8/lib/libguile-dbi.so", >> > message >> > "/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: >> > version `GLIBC_2.33' not found (required by >> > /gnu/store/z0kk97dcbcj6s8crm3qiwsyz4ry0zqxw-guile-2.2.7/lib/libguile-2.2.so.1)" > > Hey, this sounds just like the problem I reported earlier this month. Can you please tell us the issue number? >> The problem you describe looks like you have a mixture of packages that >> have been linked with different versions of the GNU C library, which >> indicates that you used different versions of Guix to build/install >> them. > > Is this possible at all? Aren’t builds atomic, and isn’t guix version > change considered an input change, so that builds by various guix > versions are prevented by design from being mixed while linking? Builds are isolated, of course, but it’s common that people who don’t use manifests end up building a profile that consists of a colorful mosaic of packages from different versions of Guix. guix install foo guix pull guix install bar guix pull guix install baz With enough time between the last action and “guix pull”, “foo”, “bar”, and “baz” could all be linked with different libraries. This is usually not even a problem, unless they all have to be used in the same process, e.g. if “bar” is a plugin to the “foo” programming language. -- Ricardo
