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 563034 - .mo are installed in /usr/lib rather than /usr/share under FreeBSD
.mo are installed in /usr/lib rather than /usr/share under FreeBSD
Status: RESOLVED NOTGNOME
Product: intltool
Classification: Deprecated
Component: general
0.40.x
Other All
: Normal normal
: ---
Assigned To: intltool maintainers
intltool maintainers
Depends on:
Blocks:
 
 
Reported: 2008-12-02 21:35 UTC by Sylvain Beucler
Modified: 2009-07-12 22:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sylvain Beucler 2008-12-02 21:35:44 UTC
Please describe the problem:
intltool.m4 defaults DATADIRNAME to 'lib' when it can't link the _nl_msg_cat_cntr function - i.e. GNU gettext.

This is a bug in the following situation:
- FreeBSD is used: unlike under GNU/Linux, gettext isn't present unless you explicitely specify -lintl -L/usr/local/lib
- The project doesn't link with libintl/gettext directly, but uses it indirectly as part of a framework (in my case, wxGtk/wxWidgets)

Relevant M4 code in /usr/share/aclocal/intltool.m4:

  # 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)


Steps to reproduce:
1. Install FreeBSD 6.4
2. Download http://www.freedink.org/releases/dfarc-3.2.1.tar.bz2
3. pkg_add -r wxgtk2-unicode
   pkg_add -r bzip2 # also installs libbz2
   pkg_add -r intltool
   pkg_add -r gmake
4. ./configure && gmake
5. cd po/ && gmake install
# incidentally Makefile.in.in doesn't seem to work in FreeBSD's make


Actual results:
DATADIRNAME is set to 'lib' and .mo files are installed in /usr/local/lib/

freebsd# cd po
freebsd# make install
Error expanding embedded variable.
freebsd# gmake install
/bin/sh /root/dfarc-3.2.1/autotools/install-sh -d /usr/local/lib/locale
linguas="fr pl fi "; \
	for lang in $linguas; do \
	  dir=/usr/local/lib/locale/$lang/LC_MESSAGES; \
	  /bin/sh /root/dfarc-3.2.1/autotools/install-sh -d $dir; \
	  if test -r $lang.gmo; then \
	    /usr/bin/install -c -m 644 $lang.gmo $dir/dfarc.mo; \
	    echo "installing $lang.gmo as $dir/dfarc.mo"; \
	  else \
	    /usr/bin/install -c -m 644 ./$lang.gmo $dir/dfarc.mo; \
	    echo "installing ./$lang.gmo as" \
		 "$dir/dfarc.mo"; \
	  fi; \
	  if test -r $lang.gmo.m; then \
	    /usr/bin/install -c -m 644 $lang.gmo.m $dir/dfarc.mo.m; \
	    echo "installing $lang.gmo.m as $dir/dfarc.mo.m"; \
	  else \
	    if test -r ./$lang.gmo.m ; then \
	      /usr/bin/install -c -m 644 ./$lang.gmo.m \
		$dir/dfarc.mo.m; \
	      echo "installing ./$lang.gmo.m as" \
		   "$dir/dfarc.mo.m"; \
	    else \
	      true; \
	    fi; \
	  fi; \
	done
installing fr.gmo as /usr/local/lib/locale/fr/LC_MESSAGES/dfarc.mo
installing pl.gmo as /usr/local/lib/locale/pl/LC_MESSAGES/dfarc.mo
installing fi.gmo as /usr/local/lib/locale/fi/LC_MESSAGES/dfarc.mo


Expected results:
DATADIRNAME is set to 'share' and .mo files are installed in /usr/local/share/

Does this happen every time?
Yes

Other information:
Currently the FreeBSD package is using a quick patch:

  http://www.freebsd.org/cgi/cvsweb.cgi/ports/games/freedink-dfarc/files/patch-po_Makefile.in.in?rev=1.1

It would be nice to fix intltool.m4 so as to avoid this patch.
Comment 1 Rodney Dawes 2009-07-12 22:01:04 UTC
Moved to Launchpad.

https://bugs.edge.launchpad.net/intltool/+bug/398571