View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001453 | gnunet-gtk | public | 2009-02-13 14:40 | 2010-10-21 15:47 | |
| Reporter | holin | Assigned To | Christian Grothoff | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0001453: gnunet-gtk makes false assumptions abouts paths | ||||
| Description | When gnunet-gtk is installed with another --prefix= than the GNUnet, which it was linked with. It doesn't quite work. As an example, when GNUnet --prefix=/tmp/GNU and gnunet-gtk --prefix=/tmp/GTK, the following comes out when starting gnunet-gtk: (gnunet-gtk:13843): libglade-WARNING **: could not find glade file '/tmp/GTK/share/GNUnet//../gnunet-gtk/gnunet-gtk.glade' Feb 13 23:35:15 FATAL: `glade_xml_new' failed on file `/tmp/GTK/share/GNUnet//../gnunet-gtk/gnunet-gtk.glade' at helper.c:377 with error: No such file or directory Aborted | ||||
| Tags | No tags attached. | ||||
|
|
That's because gnunet-gtk uses gnunetutil to resolve paths... Would it be OK to just require that both paths be equal? |
|
|
If it used GNUNET_IPK_PREFIX and "share/gnunet-gtk/..." instead of GNUNET_IPK_DATADIR and "../gnunet-gtk/...", I think, it would work in the general case. Only when GNUNET_PREFIX is set or when get_installation_path() has to use the PATH strategy would it fail. Configure should however warn the user that things might not work when --prefix is different from --with-gnunet. |
|
|
On a closer look, the whole thing needs a rehash. IMO: - GNUNET_get_installation_path() should always return paths that are related to the GNUnet install location, NOT to the caller's binary. So, the path should be acquired, similar to what LE does, from the install location of libgnunetutil instead of gnunetd. - if it's deemed generally useful, there should be another function in gnunetutil that gets the current executable's (or maybe any named executable's, if really desperate) path, which could then be used by gnunet-gtk and alike. |
|
|
Feel free to fix; however, instead of adding a new function, I suggest you extend the set of the IPK-constants. |
|
|
Mostly fixed now, but gnunet-gtk module loading doesn't work. Either the env for module loader needs to be set to the plugins dir (of gnunet-gtk), or GNUNET_plugin_load would need to be augmented with a path argument, which could be NULL to use the default search path. |
|
|
Moving this to the 0.9.x branch since the required API change should certainly happen for this branch. |
|
|
Fixed in svn 12213. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-02-13 14:40 | holin | New Issue | |
| 2009-02-13 22:13 | Christian Grothoff | Note Added: 0003807 | |
| 2009-02-13 23:27 | holin | Note Added: 0003808 | |
| 2009-02-14 03:34 | holin | Note Added: 0003809 | |
| 2009-02-14 23:33 | Christian Grothoff | Note Added: 0003812 | |
| 2009-02-14 23:34 | Christian Grothoff | Assigned To | => holin |
| 2009-02-14 23:34 | Christian Grothoff | Status | new => assigned |
| 2009-02-16 03:29 | holin | Note Added: 0003815 | |
| 2009-11-15 14:49 | Christian Grothoff | Project | GNUnet 0.8.x => gnunet-gtk |
| 2009-11-15 14:49 | Christian Grothoff | Note Added: 0003895 | |
| 2009-11-15 14:49 | Christian Grothoff | Assigned To | holin => |
| 2009-11-18 02:15 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2010-07-12 13:47 | Christian Grothoff | Note Added: 0004067 | |
| 2010-07-12 13:47 | Christian Grothoff | Status | assigned => resolved |
| 2010-07-12 13:47 | Christian Grothoff | Resolution | open => fixed |
| 2010-10-21 15:47 | Christian Grothoff | Status | resolved => closed |
| 2011-09-15 14:18 | Christian Grothoff | Category | gnunet-gtk => (No Category) |
