To say it a bit more bluntly: Using the GNUnet configuration as your own application's configuration was never a good idea. After all, none of the paths actually belong to your application and you probably should not mess with any of those.
This is why you should pass your applications own ProjectData to GNUNET_PROGRAM_run and friends. Of course it is understandable that you want to use GNUnet services and connect to them. That is why GNUnet's config is still available for you to use. You can check out gnunet-gtk on how that is supposed to happen now. (Commit https://git.gnunet.org/gnunet-gtk.git/commit/?id=2e31cdf347d2fe93b6d388693027771b94fa60ef) BR Martin On Tue, 2024-12-10 at 17:27 +0100, Alessio Vanni wrote: > Hello, > > GNUnet 0.23 changed the way GNUNET_OS_ProjectData is used, moving it > from being global state to a function parameter in commit > 9ab62c62c3d508033d31ea5289013255ec7a0c87. > > The same commit also removes the GNUNET_CONFIGURATION_default > function > to return a new configuration object with GNUnet's "default" values. > > This removal breaks third-party applications with a > GNUNET_OS_ProjectData that is different from GNUnet's own, because > the > configuration object given as argument to the "main" function called > by > e.g. GNUNET_PROGRAM_run does not contain the values GNUnet expects. > > I have attached a minimal test program to explain the issue. Compile > it > with: > gcc -o mybinary $(pkg-config --cflags gnunetutil) test.c $(pkg-config > --libs gnunetutil) > > then start GNUnet and execute the mybinary program. You will see that > the program is not able to detect whether the GNS service is > available > or not despite being running. > > The only way to make it work is to use GNUnet's configuration, but > there > is no way to obtain it without replicating GNUnet's logic (reading > env > variables, expanding paths, using defaults, etc.) which is something > third-party applications should never do. > > GNUNET_CONFIGURATION_create() only sets some path values, it does not > load the actual configuration and that makes it unsuitable to connect > to > services due to missing important values found in each service's > section > of the configuration. > > Applications which do not need to set a different project data value > are > not affected, since they can use GNUnet's own one. > > Thank you, > A. V.
