View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008962 | GNUnet | util library | public | 2024-06-19 00:11 | 2024-12-09 18:03 |
| Reporter | noe | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Platform | x86_64 | OS | GNU Guix | ||
| Product Version | 0.21.2 | ||||
| Target Version | 0.23.0 | Fixed in Version | 0.23.0 | ||
| Summary | 0008962: gnunet-setup fails to find libexec libraries | ||||
| Description | Hi, I'm still trying to make gnunet work on Guix, I'm starting to understand more things and I've encountered an issue caused by gnunet-gtk being in a different directory than gnunet. For context, because Guix needs reproducible builds and because gnunet and gnunet-gtk are two different packages, gnunet is built normally and installed in the /gnu/store/…-gnunet-0.21.2/. This includes the lib/gnunet/libexec directory. Similarly, gnunet-gtk is built with --with-gnunet pointing to the first package and installed in its own directory /gnu/store/…-gnunet-gtk-0.21.0/. The problem arises when gnunet-gtk tries accessing libexec binaries, for example gnunet-daemon-hostlist, it will call « GNUNET_OS_get_libexec_binary_path ("gnunet-daemon-hostlist")» (gnunet-setup-hostlist-server.c:160). This will incorrectly return gnunet-gtk's installation directory instead of the gnunet directory that contains the binaries. As a simple fix, I tried setting GNUNET_PREFIX to the gnunet directory, but this prevents gnunet-gtk from finding its own files. Should GNUNET_OS_get_libexec_binary_path be changed to return its own libexec directory instead of the caller's or is there a variable I can tweak in the packaging ? Thank you for your time, Noé Lopez | ||||
| Steps To Reproduce | Using guix: $ guix shell gnunet gnunet-setup $ touch ~/.config/gnunet.conf $ gnunet-setup then go into the hostlist tab Building from source: install gnunet in directory A configure gnunet-gtk with --with-gnunet=A install gnunet-gtk in directory B $ gnunet-setup then go into the hotlist tab, it should then error saying it doesn't find the libexec binaries | ||||
| Additional Information | Errors caused by this issue: 2024-06-18T23:05:35.012733+0200 util-os-installation-26661 WARNING `access' failed on file `/gnu/store/9gqix8hbbhsh09zxz975bisc80x2vjgn-gnunet-gtk-0.21.0/gnunet/libexec/gnunet-daemon-hostlist' at os_installation.c:793 with error: Aucun fichier ou dossier de ce type 2024-06-18T23:05:35.013009+0200 gnunet-setup-26661 WARNING Could not determine whether the hostlist daemon has an integrated hostlist server! 2024-06-18T23:50:57.763772+0200 util-os-installation-30107 WARNING `access' failed on file `/gnu/store/9gqix8hbbhsh09zxz975bisc80x2vjgn-gnunet-gtk-0.21.0/gnunet/libexec//gnunet-service-resolver' at os_installation.c:793 with error: Aucun fichier ou dossier de ce type 2024-06-18T23:50:57.763812+0200 gnunet-setup-30107 ERROR `exec' failed on file `/gnu/store/9gqix8hbbhsh09zxz975bisc80x2vjgn-gnunet-gtk-0.21.0/gnunet/libexec//gnunet-service-resolver' at gnunet-setup-transport-test.c:135 with error: Aucun fichier ou dossier de ce type 2024-06-18T23:50:57.764699+0200 util-os-installation-30107 WARNING `access' failed on file `/gnu/store/9gqix8hbbhsh09zxz975bisc80x2vjgn-gnunet-gtk-0.21.0/gnunet/libexec//gnunet-service-nat' at os_installation.c:793 with error: Aucun fichier ou dossier de ce type 2024-06-18T23:50:57.764709+0200 gnunet-setup-30107 ERROR `exec' failed on file `/gnu/store/9gqix8hbbhsh09zxz975bisc80x2vjgn-gnunet-gtk-0.21.0/gnunet/libexec//gnunet-service-nat' at gnunet-setup-transport-test.c:135 with error: Aucun fichier ou dossier de ce type 2024-06-18T23:50:57.766051+0200 util-os-installation-30107 WARNING `access' failed on file `/gnu/store/9gqix8hbbhsh09zxz975bisc80x2vjgn-gnunet-gtk-0.21.0/gnunet/libexec//gnunet-service-nat-auto' at os_installation.c:793 with error: Aucun fichier ou dossier de ce type 2024-06-18T23:50:57.766066+0200 gnunet-setup-30107 ERROR `exec' failed on file `/gnu/store/9gqix8hbbhsh09zxz975bisc80x2vjgn-gnunet-gtk-0.21.0/gnunet/libexec//gnunet-service-nat-auto' at gnunet-setup-transport-test.c:135 with error: Aucun fichier ou dossier de ce type 2024-06-18T23:50:57.766106+0200 gnunet-setup-30107 ERROR Failed to find valid PORT in section `transport-udp' | ||||
| Tags | No tags attached. | ||||
|
|
I am currently trying to use gdb to see exactly where the path finding fails |
|
|
I have found the exact cause of the issue, in the function os_get_gnunet_path(). It first tries getting the path from the GNUNET_PREFIX, but that is not possible. Then it tries from proc maps, but that returns the gnunet-setup's path, instead of gnunet-arm. This is where it returns the wrong value. After, it would have tried getting it from PATH which could work, but it returns a symbolic link's path. Lastly, it would have tried /proc/exe, but that also returns the gnunet-setup path. If I understand correctly, the two /proc functions are assuming that the caller's path is the same as the gnunet path, which is not necessarily the case as gnunet-gtk is a different package and thus might call the function from a different directory. A solution could be prioritizing checking PATH before /proc, and making sure it dereferences symbolic links. I'd be happy to provide a patch for that, or something else if there is a better solution. Thanks for your time and good night :) |
|
|
My guess is that this is actually a bug in gnunet-gtk. os_get_gnunet_path() should obviously return the path to gnunet's libexec. The logic for an application return its own libexec path should be different (potentially). We certainly did not indent that gnunet-gtk MUST be installed into the same prefix as gnunet. Unfortunately, I cannot really move this issue into the gnunet-gtk project I think, so let's keep it here. |
|
|
Yes it must be an issue with gnunet-gtk as even when changing os_get_gnunet_path() to always return the gnunet path is will fail to find other files from gnunet-gtk. So I think there are two bugs, 1) os_get_gnunet_path() fails to find the good prefix and instead returns gnunet-gtk's. 2) gnunet-gtk is looking for its own files in the gnunet prefix instead of its own. |
|
|
Well, we *did* intend gnunet-gtk and gnunet to be installed in the same directory. Problem is that that's a bad assumption, but also one that is not easy to fix. |
|
|
I think it's time to bite the bullet here and to de-globalize the GNUNET_OS_ProjectData. That's the only clean solution here. |
|
|
gnunet.git fix: cea8fd49f..9ab62c62c gnunet-gtk fix: a181cbe9..2e31cdf3 |
|
|
Released |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-06-19 00:11 | noe | New Issue | |
| 2024-06-19 00:21 | noe | Note Added: 0022671 | |
| 2024-06-19 01:04 | noe | Note Added: 0022672 | |
| 2024-06-21 11:21 | schanzen | Note Added: 0022699 | |
| 2024-06-21 11:21 | schanzen | Assigned To | => Christian Grothoff |
| 2024-06-21 11:21 | schanzen | Status | new => assigned |
| 2024-06-21 15:33 | noe | Note Added: 0022701 | |
| 2024-09-30 14:23 | Christian Grothoff | Note Added: 0023406 | |
| 2024-10-10 10:24 | schanzen | Target Version | => 1.0.0 |
| 2024-11-10 18:23 | Christian Grothoff | Note Added: 0023686 | |
| 2024-11-14 11:18 | schanzen | Target Version | 1.0.0 => 0.23.0 |
| 2024-11-14 21:38 | Christian Grothoff | Status | assigned => resolved |
| 2024-11-14 21:38 | Christian Grothoff | Resolution | open => fixed |
| 2024-11-14 21:38 | Christian Grothoff | Fixed in Version | => 0.23.0 |
| 2024-11-14 21:38 | Christian Grothoff | Note Added: 0023725 | |
| 2024-12-09 18:03 | schanzen | Note Added: 0023844 | |
| 2024-12-09 18:03 | schanzen | Status | resolved => closed |
