unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Fredrik Salomonsson <plattfot@posteo.net>
To: Laurent Gatto <laurent.gatto@gmail.com>
Cc: help-guix@gnu.org
Subject: Re: C++ error
Date: Thu, 14 Nov 2024 18:51:00 +0000	[thread overview]
Message-ID: <87r07d8x9n.fsf@posteo.net> (raw)
In-Reply-To: <CA+uNOziskAQmxd1gD8+J=T5AwMXKWegfV=Sj8LEmoqT-AZjCyg@mail.gmail.com>

Hi,

Laurent Gatto <laurent.gatto@gmail.com> writes:

> Hi Fredrik,
>
>> So something else must be affecting yours.  No idea about what that is
>> though.  Did you install guix as a package manager on top of an foreign
>> distro or is this a Guix System machine?
>
> I should have specified that this is a Guix system machine.
>
>> Also has this ever worked for you?
>
> I am not sure, to be honest. Here, I tried to report a minimally
> reproducible example of wider issues, such as documented here [1]. I
> don't know if they are directly related though.
>
> [1] https://lists.gnu.org/archive/html/help-guix/2024-08/msg00040.html
>

I don't think these two are directly related.  That one should work if
you are using glibc-2.35.  As the GLIBC_2.34 is just a symbol version
for things introduced in glibc-2.34 and should be in glibc-2.35.  I
haven't fully understand how glibc is setup in guix, i.e. if it is easy
to run multiple glibc versions at the same time.  So the issue might be
that your system is setup for glibc-2.33 but the packages have just
transitioned to 2.35.  I had some similar issues with glibc and pam
which resolved itself after I did a reconfigure.

>> If so you might trying doing a kind
>> of git bisect on your packages using `guix package --switch-generation`.
>>
>> First find a working generation with `guix package --list-generations`,
>> pick the generation that is in the middle of the latest broken
>> generation and the older working one.  Switch to that, do the test.  If
>> it works then the problem is most likely between that generation and the
>> latest broken generation.  If not, then the issue is between the current
>> generation and the older working one.  Pick the middle generation
>> between the working and broken generation and repeat.
>>
>> Just keep iterating until you find the generation that introduced the
>> issue.  Then you can compare with the previous working generation to see
>> if there are any differences in packages.
>
> I will try this. If push comes to shove, I could re-install a new Guix
> system, reinstall my packages from my manifest and re-configure my
> system and home config. This is among the reasons that brought me to
> Guix in the first place, so why not make use of it.

One great thing with guix is that you technically do not need to
re-install a new guix system from scratch.  You could create an absolute
bare minimum system and reconfigure to that.  Same with you packages.
That should give you close to what is possible to a clean re-install
without the hassel of do a clean re-install.  And with that you can
easily switch back to your normal config with switch-generations when
you are done.  Which is a similar technique to the generation bisect I
suggested earlier.

Which now that I think of it might be a better way to go for you as you
are not sure if you had a working generation.  Same principle as with
the generations, but this time you apply it to all of your packages
installed.  Easiest if you have a manifest/home config etc.  Just
comment out all packages so you only have gcc-toolchain installed.  See
if that works, which it most likely will given that it works in the guix
shell container.  Then enable half of your packages, reconfigure and see
if things still work.  If it does, the issue is not in the packages you
enable but in the other half.  Enable that and repeat.  If things are
now broken then you know the issue is in some of the packages you
enabled.  So comment out a half of that and repeat.

> Thanks again for taking the time to help.

No worries, I hope you can figure out what the issue is.

-- 
s/Fred[re]+i[ck]+/Fredrik/g


  reply	other threads:[~2024-11-14 18:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-12  7:41 C++ error Laurent Gatto
2024-11-12 17:54 ` Fredrik Salomonsson
2024-11-12 20:26   ` Laurent Gatto
2024-11-13  0:50     ` Fredrik Salomonsson
2024-11-13  6:49       ` Laurent Gatto
2024-11-13 19:12         ` Fredrik Salomonsson
2024-11-13 21:33           ` Laurent Gatto
2024-11-14 18:51             ` Fredrik Salomonsson [this message]
2024-11-16 10:56               ` Laurent Gatto
2024-11-16 13:19                 ` Laurent Gatto
2024-11-18 18:49                   ` Fredrik Salomonsson
2024-11-21  8:50                     ` Laurent Gatto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r07d8x9n.fsf@posteo.net \
    --to=plattfot@posteo.net \
    --cc=help-guix@gnu.org \
    --cc=laurent.gatto@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).