readline problem

readline problem

[jsmith via]

Hi,
For some code that was previously working I receive the error:

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)"

I installed glibc_2.33 and if I guix package --list-installed it appears to be installed.
output:
glibc 2.33 out /gnu/store/mf8mfvw5gzq3dqblk98zqll3x7vx96c5-glibc-2.33
readline 8.1.1 out /gnu/store/3lr629jcjk0zds5nzaq9vplqgaggz0pg-readline-8.1.1

I did a guix pull, guix package -u, source profile so I am working with the latest.
Any suggestions?
Thanks
Jim

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

Re: readline problem

[Ricardo Wurmus]

jsmith via <help-guix@gnu.org> writes:

> Hi,
> For some code that was previously working I receive the error:
>
> 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)"
>
> I installed glibc_2.33

You should not do this.  It has no effect as Guix will not look around
for what version of glibc (or any other library for that matter) you
might have installed in some profile.  When building software, the
absolute file names of libraries are embedded in the binary — including
the GNU C library.

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.

Here an older version of the C library is loaded first because some
package you have is linked with that older version.  Then at a later
point a package demands to use features that only a newer version of the
C library provides, but the older version that has been loaded cannot
satisfy the request.  This problem is not specific to Guix and is shared
by all systems that use dynamic linking.  There is no way to load
different variants of the same library in the same process.

The solution is to make sure that all software that has to work together
uses the same variants of any libraries.  Guix by default only keeps one
variant per library in its set of package definitions, so by using the
same version of Guix for all packages that are used simultaneously will
bypass the problem.

There are different ways out of this problem:

a) use a manifest to ensure that all packages in your profile are
installed with the exact same version of Guix and thus use the same
variants for all libraries

b) upgrade all your packages with the same version of Guix.

c) use a temporary isolated environment, e.g. with “guix shell -C”

Hope this helps!

-- 
Ricardo

Re: readline problem

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

On Mon, Jan 17, 2022 at 12:57:54PM +0100, Ricardo Wurmus wrote:
>
> jsmith via <help-guix@gnu.org> 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.

   /gnu/store/bb27inmp90vyx59q1453zl1rs9h73kjd-guile-wrapper/bin/guile: /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/3lsrx30nl5cacva8a8rd2xy08xlszx14-libx11-1.7.2/lib/libX11.so.6)
   /gnu/store/bb27inmp90vyx59q1453zl1rs9h73kjd-guile-wrapper/bin/guile: /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/2sgw9si0va897m6mvgwmv9ilx6szqxc8-libxau-1.0.9/lib/libXau.so.6)
   /gnu/store/bb27inmp90vyx59q1453zl1rs9h73kjd-guile-wrapper/bin/guile: /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/7x63qm1byi8j72rd4nkv01nbpqvrr80s-libbsd-0.10.0/lib/libbsd.so.0)

> 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?

> Here an older version of the C library is loaded first because some
> package you have is linked with that older version.

Again, could it be a system-wide version: the system build with guix X,
guix upgraded to X+1, user package built with guix X+1, while the system
is still at guix X, so that the package links to system-wide libc build
with guix X?

> a) use a manifest to ensure that all packages in your profile are
> installed with the exact same version of Guix and thus use the same
> variants for all libraries

> c) use a temporary isolated environment, e.g. with “guix shell -C”

My bug is produced when I use a manifest and an isolated environment. I
also discovered that I’m getting the same errors while loading profiles.
Rebuilding profiles (with a newer guix as they’re not time-machined with
some exceptions) fixes this.

WŻ

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: readline problem

[Ricardo Wurmus]

Wiktor Żelazny <wz@freeshell.de> writes:

> [[PGP Signed Part:Undecided]]
> On Mon, Jan 17, 2022 at 12:57:54PM +0100, Ricardo Wurmus wrote:
>>
>> jsmith via <help-guix@gnu.org> 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

Re: readline problem

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

On Tue, Jan 18, 2022 at 03:51:35PM +0100, Ricardo Wurmus wrote:
>
> Wiktor Żelazny <wz@freeshell.de> writes:
>
> > Hey, this sounds just like the problem I reported earlier this
> > month.
>
> Can you please tell us the issue number?

I did not file an issue as I wasn’t sure if that was a bug. I’m talking
about the “"libc.so.6: version `GLIBC_2.33' not found" with guix
time-machine --channels” thread on this mailing list, started on January
8th.

> 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

I suppose that this problem does not arise if `guix package -u` is run
after each `guix pull`?

WŻ

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: readline problem

[Ricardo Wurmus]

Wiktor Żelazny <wz@freeshell.de> writes:

> [[PGP Signed Part:Undecided]]
> On Tue, Jan 18, 2022 at 03:51:35PM +0100, Ricardo Wurmus wrote:
>>
>> Wiktor Żelazny <wz@freeshell.de> writes:
>>
>> > Hey, this sounds just like the problem I reported earlier this
>> > month.
>>
>> Can you please tell us the issue number?
>
> I did not file an issue as I wasn’t sure if that was a bug. I’m talking
> about the “"libc.so.6: version `GLIBC_2.33' not found" with guix
> time-machine --channels” thread on this mailing list, started on January
> 8th.

Oh, okay.  I thought there had been a bug report with a discussion I
missed.

>> 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
>
> I suppose that this problem does not arise if `guix package -u` is run
> after each `guix pull`?

It should not happen then, correct.

Though I have had reports from confused users at work who say that “guix
upgrade” doesn’t necessarily help, and that they actually had to use
“guix install” on all packages again.  I haven’t been able to confirm
this yet.

-- 
Ricardo

Re: readline problem

[James Smith]

So it seems that guix pull should always be followed by guix package -u ?

If so, why doesn't guix pull just do the upgrade?

Thanks
Jim

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, January 19th, 2022 at 2:45 PM, Ricardo Wurmus <rekado@elephly.net> wrote:

> Wiktor Żelazny wz@freeshell.de writes:
>
> > [[PGP Signed Part:Undecided]]
> >
> > On Tue, Jan 18, 2022 at 03:51:35PM +0100, Ricardo Wurmus wrote:
> >
> > > Wiktor Żelazny wz@freeshell.de writes:
> > >
> > > > Hey, this sounds just like the problem I reported earlier this
> > > >
> > > > month.
> > >
> > > Can you please tell us the issue number?
> >
> > I did not file an issue as I wasn’t sure if that was a bug. I’m talking
> >
> > about the “"libc.so.6: version `GLIBC_2.33' not found" with guix
> >
> > time-machine --channels” thread on this mailing list, started on January
> >
> > 8th.
>
> Oh, okay. I thought there had been a bug report with a discussion I
>
> missed.
>
> > > 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
> >
> > I suppose that this problem does not arise if `guix package -u` is run
> >
> > after each `guix pull`?
>
> It should not happen then, correct.
>
> Though I have had reports from confused users at work who say that “guix
>
> upgrade” doesn’t necessarily help, and that they actually had to use
>
> “guix install” on all packages again. I haven’t been able to confirm
>
> this yet.
>
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Ricardo

Re: readline problem

[Ricardo Wurmus]

James Smith <jsmith8365@protonmail.com> writes:

> So it seems that guix pull should always be followed by guix package -u ?

No, I don’t think it’s correct to say that.  You can use your updated
Guix to do a lot of things that are completely unrelated to the state of
your default profile.

- install things to a different profile
- use “guix shell” for an ad-hoc environment
- use “guix pack” to build a portable archive
- reconfigure your system with your new Guix
…

There are also good reasons why you wouldn’t want to upgrade your
default profile every time you upgrade Guix.  Software in your default
profile may not actually build with the current version of Guix, or you
are perfectly happy with the version you have installed, or for
reproducibility reason you really want to stay with the current
well-known versions and only add a new independent tool…

There are problems with gradually building up state in a Guix profile by
consecutively adding packages installed with a different version of
Guix, but this is not a good reason to couple “guix pull” with upgrades
of your profile(s).

-- 
Ricardo

No upgrade after pull, and Guix philosophy (was: readline problem)

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]

On Fri, Jan 28, 2022 at 12:22:51PM +0100, Ricardo Wurmus wrote:

> There are also good reasons why you wouldn’t want to upgrade your
> default profile every time you upgrade Guix.  Software in your default
> profile may not actually build with the current version of Guix, or you
> are perfectly happy with the version you have installed, or for
> reproducibility reason you really want to stay with the current
> well-known versions and only add a new independent tool…

This sounds rather brittle: you need to keep things in your head. It’s
like being a liar: you need to remember what lie you told to what
person. And then you make an error and your byzantine construction (of
software versions or lies) falls down.

Is this in the spirit of Guix at all? I mean, is this functional package
management? Wouldn’t it be nicer to have manifests support an additional
(optional) field, viz. guix commit corresponding to given package, and
manage your profile using that explicit manifest file? Or aren’t
inferiors suitable for such purpose?

WŻ

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: No upgrade after pull, and Guix philosophy (was: readline problem)

[Ricardo Wurmus]

Wiktor Żelazny <wz@freeshell.de> writes:

>> There are also good reasons why you wouldn’t want to upgrade your
>> default profile every time you upgrade Guix.  Software in your default
>> profile may not actually build with the current version of Guix, or you
>> are perfectly happy with the version you have installed, or for
>> reproducibility reason you really want to stay with the current
>> well-known versions and only add a new independent tool…
>
> This sounds rather brittle: you need to keep things in your head.

I don’t follow.  I don’t see what you’re referring to as “brittle” and
what you need to keep in your head.

> Wouldn’t it be nicer to have manifests support an additional
> (optional) field, viz. guix commit corresponding to given package, and
> manage your profile using that explicit manifest file? Or aren’t
> inferiors suitable for such purpose?

You can manage your profile with a manifest; in fact, we recommend
that.  But it’s not mandatory, and that’s key here.  Manifests aren’t
always the best fit.

And yes, you can use inferiors in your manifest to build a profile made
of packages from different versions of different channels explicitly.

-- 
Ricardo

Re: No upgrade after pull, and Guix philosophy (was: readline problem)

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Sun, Jan 30, 2022 at 09:53:14AM +0100, Ricardo Wurmus wrote:
>
> Wiktor Żelazny <wz@freeshell.de> writes:
>
> > This sounds rather brittle: you need to keep things in your head.
>
> I don’t follow.  I don’t see what you’re referring to as “brittle” and
> what you need to keep in your head.

When upgrading your packages you need to remember every time which ones
you want to keep at their current versions (in the broad sense) and, to
my understanding, juggle with regexpes, so that they’re excluded from an
upgrade. What if you upgrade them by accident? How do you roll-back and
how do you know to which corresponding Guix commit you should roll-back
to?

A manifest would let you be more organized. You can put comments there,
you can manage it with version control.

WŻ

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: No upgrade after pull, and Guix philosophy (was: readline problem)

[Ricardo Wurmus]

Wiktor Żelazny <wz@freeshell.de> writes:

> [[PGP Signed Part:Undecided]]
> On Sun, Jan 30, 2022 at 09:53:14AM +0100, Ricardo Wurmus wrote:
>>
>> Wiktor Żelazny <wz@freeshell.de> writes:
>>
>> > This sounds rather brittle: you need to keep things in your head.
>>
>> I don’t follow.  I don’t see what you’re referring to as “brittle” and
>> what you need to keep in your head.
>
> When upgrading your packages you need to remember every time which ones
> you want to keep at their current versions (in the broad sense) and, to
> my understanding, juggle with regexpes, so that they’re excluded from an
> upgrade. What if you upgrade them by accident? How do you roll-back and
> how do you know to which corresponding Guix commit you should roll-back
> to?
>
> A manifest would let you be more organized. You can put comments there,
> you can manage it with version control.

Sure, that’s why they exist.  But it’s fine to offer both interfaces.

The imperative interface exists because it is common and does not
require much learning at all.  When the convenience it provides is
outmatched by the downsides of imperative package management users can
migrate to manifests.

-- 
Ricardo

Re: readline problem

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]


>> Though I have had reports from confused users at work who say that “guix
>> upgrade” doesn’t necessarily help, and that they actually had to use
>> “guix install” on all packages again. I haven’t been able to confirm
>> this yet.

I had that problem, too. It’s why I switched to manifests: I could not
upgrade, but had to add more and more packages to the upgrade, maybe
choosing different versions to get them consistent.

I think that it was because guix upgrade keeps some version information,
so it might have too strict constraints when calculating the next
possible state.

Then I get something like "package conflict: dbus5 in profile and dbus4
pulled in by emacs". (not actual version numbers, this is just an example)

I’d like to have the situation where I can just say `guix upgrade emacs`
and guix calculates all affected packages recursively, resolving version
conflicts by itself to find the set of packages that need to be upgraded.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]