Ok, then I'm not sure how you expect this to work: if you do not give
the code access to the configuration data (i.e. by telling it to load it
from a different directory than where GNUnet was installed and also not
providing the right configuration information in that directory), then
obviously the logic will fail when it needs its configuration.

Note that you can use GNUNET_CONFIGURATION_load* with the "right"
path(s) to manually load either the GNUnet configuration data or your
own applications' configuration data (if they are in different
locations). However, without such manual action on your part,
libgnunetutil will by design only load the configuration data from the
one location that is configured via the ProjectData mechanism.

Does this help?

On 9/10/19 9:41 PM, Alessio Vanni wrote:
> Sorry for the late reply.  I didn't see there was a reply to the report
> (I'm not subscribed to this list... I check the archives from time to
> time though.)
> 
>> This shouldn't be the case, as GNUnet picks up the (default) service
>> contact information from a the share/gnunet/config.d/ directory.
>>
>> Also, when I change the value, everything still works for me. What is
>> the error message you are seeing (if any)?
> 
> The problem is in 3rd-party applications.  GNUnet itself correctly reads
> its config files from the correct directories.  However, if the
> GNUNET_OS_ProjectData structure holds different values, the application
> doesn't work.
> 
> The main problem is that it can't connect to GNUnet services, so the
> error is that `GNUNET_CLIENT_connect' returns NULL when making a
> connection.
> 
> For a concrete error message, using `GNUNET_IDENTITY_ego_lookup' (which
> makes an implicit connection to the IDENTITY service) when .config_file
> and .user_config_file are different from "gnunet.conf" and
> "~/.config/gnunet.conf" respectively, it fails with the following
> message:
> 
> ERROR Assertion failed at identity_api_lookup.c:202.
> 
> The line in question is a `GNUNET_break' called when
> `GNUNET_CLIENT_connect' returns NULL.
> 
> The error does not happen if the configuration file (either one, as long
> as it exists) is the same as GNUnet itself.
> 
> I attached a minimal program for testing this issue.  It simply calls
> `GNUNET_IDENTITY_ego_lookup'.  If it successfully connects, it will
> print wether or not the ego "test-ego" exists; otherwise, it will fail
> with the above message.
> 
> Thanks,
> A.V.
> 
> 
> _______________________________________________
> Bug-GNUnet mailing list
> Bug-GNUnet@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-gnunet
> 

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Bug-GNUnet mailing list
Bug-GNUnet@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnunet

Reply via email to