After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 354874 - Data dir path is set to /local/gnome/head/test/share/goffice/0.2.1/glade/
Data dir path is set to /local/gnome/head/test/share/goffice/0.2.1/glade/
Status: RESOLVED FIXED
Product: libgoffice
Classification: Other
Component: General
unspecified
Other Linux
: Normal major
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2006-09-08 00:30 UTC by Hugo Villeneuve
Modified: 2007-03-11 09:48 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
fixes this issue (357 bytes, patch)
2007-03-10 21:24 UTC, Jean Bréfort
committed Details | Review

Description Hugo Villeneuve 2006-09-08 00:30:23 UTC
The datadir path seems to be incorrectly set to /local/gnome/head/test/share/goffice/0.2.1/glade/ in the goffice installation. I saw that because Gnumeric crashed with the following message while trying to format a cell:

(gnumeric:25826): libglade-WARNING **: could not find glade file '/local/gnome/head/test/share/goffice/0.2.1/glade/go-rotation-sel.glade'
(gnumeric:25826): libglade-WARNING **: could not find glade file '/local/gnome/head/test/share/goffice/0.2.1/glade/go-format-sel.glade'
Segmentation fault

It seems the default path /local/gnome/head/test/share/goffice/0.2.1/glade/ is set in the file goffice/goffice-paths.h. I think this file should be remade when running configure, but it is not.

I got rid of the problem by removing the file goffice/goffice-paths.h, and then running ./configure && make && make install. After that, no more problems.
Comment 1 Jean Bréfort 2006-09-08 05:24:23 UTC
goffice/goffice-paths.h depends on goffice/Makefile itself written by configure, so that if you run make after configure, the paths are updated. Seems configure had been run with --prefix=/local
If not, we would need a way to reproduce this bug.
Comment 2 Hugo Villeneuve 2006-09-08 23:50:41 UTC
What triggers the bug is using a separate build directory. Steps to reproduce the bug:

$> tar -zxvf goffice-0.2.1.tar.gz
$> mkdir goffice-0.2.1-build
$> cd goffice-0.2.1-build
$> ../goffice-0.2.1/configure --prefix=/usr
$> make

If I do not use a separate build directory, there is no bug.



Comment 3 Jean Bréfort 2006-09-09 06:46:50 UTC
with your commands, I obtain:

/* This file has been automatically generated.  Do not edit. */

#ifndef GOFFICE_PATHS_H
#define GOFFICE_PATHS_H

#define GOFFICE_DATADIR "/usr/share/goffice/0.2.1"
#define GOFFICE_LIBDIR "/usr/lib/goffice/0.2.1"
#define GOFFICE_ICONDIR "/usr/share/pixmaps/goffice"
#define GOFFICE_LOCALEDIR "/usr/share/locale"

#endif /* GOFFICE_PATHS_H */

which is of course correct. If the separate build directory was the problem, we would have catched it with make discheck.
Comment 4 Andreas Köhler 2007-03-09 22:38:51 UTC
Confirming because I just ran into this as well.  Jean, which goffice-paths.h do you mean?  There should be one in the source and one in the build directory, where the primer is in use.
Comment 5 Jean Bréfort 2007-03-10 07:19:52 UTC
OK, understood, we ship a version of goffice-paths.h in the sources with these paths. This should not be, only the generated one, in the build directory, should be used.
Solution: we must remove the goffice-paths.h from the tarball. In the mean time, just remove it before compiling.
Comment 6 Jean Bréfort 2007-03-10 21:24:38 UTC
Created attachment 84358 [details] [review]
fixes this issue
Comment 7 Jean Bréfort 2007-03-10 21:37:52 UTC
patch commited to HEAD
Comment 8 Emmanuel Pacaud 2007-03-11 09:48:33 UTC
*** Bug 394183 has been marked as a duplicate of this bug. ***