<apteryx>regarding my question about GNU Global header files navigation (ggtags mode in Emacs), I found that I could simply link the entry in my C_INCLUDE_PATH to my project dir, and run gtags in the project dir to pick those symbols. It's detailed in the GNU Global manual.
<apteryx>OK, I've found that in sdl2 the SDL_LoadObject function is defined in the file ./src/loadso/dlopen/SDL_sysloadso.c...
<apteryx>i.e., handle = dlopen(sofile, RTLD_NOW|RTLD_LOCAL);, where sofile is a string such as "libgtk-3.so.0".
<apteryx>hmm... The ELF binary has a RUNPATH defined, which is searched by dlopen, but it doesn't seem to include GTK: objdump -x /gnu/store/gpwds7haa6hd8n5sc18gybikjx5klbma-openboardview-7.3/bin/.openboardview-real | grep -i runpath | grep -i gtk
<emacsomancer>hello guix, I know I've asked about this before, but I'm having trouble again on a foreign distro with the "failed to install locale" issue, even after installing "glibc-locales"
<lfam>Okay, you need to update the packages of the user from whom you are seeing the messages, make sure to relogin so that your environment is setup correctly, and update and restart guix-daemon as well
<lfam>The messages either mean that GUIX_LOCPATH isn't set up at all, is setup incorrectly, or that it's different for your user and for guix-daemon. The root issue is that locales are not compatible between different versions of glibc, which just got updated
<lfam>On GuixSD you can ease the transition by using the locale-libcs field in config.scm
<brendyyn>my system definiton is a random mash of things i've copy-pasted in
<necrophcodr>I know this is hardly supported, but I'd like to have some help on what is going on, and how to resolve this issue
<necrophcodr>I'm running Gentoo, and I've been installing/uninstalling Guix on/off for about 2 years now.
<necrophcodr>I realize that this may or may not be the best of ways, but it's the way I've done it
<necrophcodr>And now I'm missing a per-user profile. Is there any way to get this back?
<necrophcodr>ie in /var/guix/profiles/per-user/necrophcodr there's no content at all
<necrophcodr>oh wow, nevermind. should've spent five seconds doing something instead. after having updated it to the latest release, reloaded the guix daemon, and updating packages, and reloading the guix daemon again, it seems to have come back.
<apteryx>rekado: in what ways? it's just doing something like dlopen("libgtk-3.so.0", RTLD_NOW)
<apteryx>and libgtk-3.so.0 exists as gnu/store/m2a5bvissgi3bxfgmwyxdmyhvwzf4n6z-gtk+-3.22.30/lib/libgtk-3.so.0
<apteryx>ah do you mean I should patch it to use an absolute path? That would probably work, but I'd like to understand why the gtk+ input is not added to the RUNPATH in the first place (if it was, I'd expect it to just work :-)
<rekado>apteryx: we sometimes patch “dlopen("libgtk” to be “(string-append "dlopen(\"" (assoc-ref inputs "gtk+") "/lib/libgtk"”
<apteryx>OK; this shouldn't be necessary if gtk was in our RUNPATH, according to 'man dlopen'
<rekado>maybe the build system of the package you’re working on messes with the RUNPATH?
<apteryx>I'm using the cmake-build-system, which is mostly like the gnu-build-system
<apteryx>who is reponsible to populate the runpath? GCC?
<rekado>have you checked if something funky is going on in CMakeLists.txt?
<rekado>because this generally works for other packages AFAICT
<apteryx>rekado: it seems to work for every other inputs I've specified for that package, except for gtk+ :-o