GNOME Bugzilla – Bug 696934
goffice 0.10.1: locales are installed to /usr/lib instead of /usr/share
Last modified: 2013-03-31 02:05:39 UTC
On a linux system (openSUSE for that matter), goffice 0.10.1 installs locale files to /usr/lib instead of /usr/share (as expected). Analysis shows (from the config.log) that the 'root cause' is -Werror=nested-extern, that was added to configure.ac (commit 759c996), but AM_GLIB_GNU_GETTEXT is not 'compatible' to this. Extract from config.log: conftest.c:36:1: warning: function declaration isn't a prototype [-Wstrict-prototypes] conftest.c: In function 'main': conftest.c:38:1: error: nested extern declaration of '_nl_msg_cat_cntr' [-Werror=nested-externs] cc1: some warnings being treated as errors configure:15693: $? = 1 aclocal contains this extract: # Set DATADIRNAME correctly if it is not set yet # (copied from glib-gettext.m4) if test -z "$DATADIRNAME"; then AC_LINK_IFELSE( [AC_LANG_PROGRAM([[]], [[extern int _nl_msg_cat_cntr; return _nl_msg_cat_cntr]])], [DATADIRNAME=share], [case $host in *-*-solaris*) dnl On Solaris, if bind_textdomain_codeset is in libc, dnl GNU format message catalog is always supported, dnl since both are added to the libc all together. dnl Hence, we'd like to go with DATADIRNAME=share dnl in this case. AC_CHECK_FUNC(bind_textdomain_codeset, [DATADIRNAME=share], [DATADIRNAME=lib]) ;; *) [DATADIRNAME=lib] ;; esac]) fi AC_SUBST(DATADIRNAME) => as AC_LANG_PROGRAM 'fails' to build (due to -Werror=nested-extern), the first DATADIRNAME=share is being skipped, then we're not solaris, so DATADIRNAME=lib is being assumed... I worked around this in my builds for now by moving AM_GLIB_GNU_GETTEXT (and the relevant other Gettext stuff, to keep it together) before the setting of the strict compiler flags... see attached patch.
Created attachment 240182 [details] [review] configure: correct LOCALEDATADIR detection. With gcc compiler flags -Werror=nested-extern, the AM_GLIB_GNU_GETTEXT macros fail, resulting in all locales being installed in $prefix/lib.
Quick note: the exact same issue happens in gnumeric (not surprising). The solution was the same;
and libgsf, one assumes. Thanks. I'll commit something like this.
not libgsf. I was wondering what the files were doing there. It's especially weird on a system that uses lib64 for the library files. This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.