<civodul>efraim: could you email firstname.lastname@example.org with the output of "uname -a" and "ldd --version", as well as the file 'log' produced by 'sudo strace -o log guix-daemon --build-users-group=guixbuild' when running something like 'guix build hello'?
<efraim>civodul: sure. right now I'm still at school but I can try to do it in a couple of hours
<mark_weaver>wingo: for me, it works on stable-2.0 but not on master.
<mark_weaver>on master I get this: Throw to key misc-error with args ("make_objcode_from_file" "bad header on object file: ~s" ("\\x7fELF\\x02\\x01\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00") #f)Aborting.
<wingo>i mean, you don't want GDB messing up because you have an environment variable set.
<wingo>that's not a failure mode i have had to consider in the past at least
<mark_weaver>well, someone might also want to customize the load path of the guile used in gdb.
<mark_weaver>so it's not clear to me that gdb should wipe those environment variables.
<mark_weaver>but maybe they should be given different names, like GDB_GUILE_LOAD_PATH et al
<mark_weaver>in such a scheme, gdb would copy GDB_GUILE_LOAD_PATH to GUILE_LOAD_PATH (and others) within its own process before initializing libguile, but propagate the inherited environment as-is to the debugged process.
<wingo>guix gdb is linked against guile 2.0, i am working on guile 2.2
<wingo>s/guile 2/python 3/ and it could be the same issue
<mark_weaver>on typical systems with software installed in fixed places on the filesystem, these kinds of environment variables are often not needed, so most users probably manage to avoid these problems.
<mark_weaver>one solution would be to support additional per-guile-major-version environment variables such as GUILE_2_2_LOAD_PATH
<wingo>yeah but i suspect with gdb that's a not-uncommon thing
<mark_weaver>so GUILE_LOAD_PATH would be consulted by any version of guile
<paroneayea>maybe building the tools you're using to hack guix in a guix environment would help?
<mark_weaver>this is a fundamental problem with environment variables / fluids / parameters: they end up propagating to places where you don't really want them to go. anything we can do to make that more focused is a good thing, IMO.
<wingo>i wonder if we will run against libtools abstractions tho
<wingo>given that libguile/guile is a libtool wrapper
<paroneayea>environment variable seem a lot worse than fluids/parameters
<mark_weaver>right, fluids/parameters essentially have two names: the name in the code is looked up lexically, and that is bound to a sort of internal name (an integer) that is used to look it up in the dynamic environment.
<mark_weaver>wingo: so, gdb allows you to set the environment for the debugged process using commands like "set environment VARNAME [=VALUE]", without setting them in the gdb process itself.
<mark_weaver>wingo: and there are -init-command and -init-eval-command options to gdb.
<mark_weaver>combining those two, I think it would be pretty easy to do it.
<efraim>how do I set my locale if I installed using the guix binary?
<efraim>I keep on getting: warning: failed to install locale: Invalid argument
<davexunit>efraim: install glibc-utf8-locales and set $LOCPATH to $HOME/.guix-profile/lib/locale
<mark_weaver>glibc-utf8-locales has only a few locales, but maybe the ones you need.
<mark_weaver>if you need other locales, one option is to create a 'locale' directory somewhere in your home dir, and use 'localedef' to generate locales in there.
<mark_weaver>(on GuixSD we handle creating a directory with your chosen locales automatically)
<mark_weaver>alternatively, we have a more extensive 'glibc-locales' package that is quite large.