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 343825 - Double expansion in m4macros/glib-gettext.m4 will fail with newer autoconf
Double expansion in m4macros/glib-gettext.m4 will fail with newer autoconf
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.11.x
Other Linux
: Normal major
: ---
Assigned To: gtkdev
gtkdev
: 344162 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-06-04 13:41 UTC by Loïc Minier
Modified: 2011-02-18 15:55 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
am-glib-define-localedir-ac2.6.patch (765 bytes, patch)
2006-11-14 22:10 UTC, James Henstridge
none Details | Review

Description Loïc Minier 2006-06-04 13:41:31 UTC
Hi,

Debian has a snapshot version (2.59.cvs.2006.06.02-2) of autoconf which defines a new intermediate directory datarootdir.

In short, old autoconf:
  --prefix=PREFIX         install architecture-independent files in PREFIX
  --datadir=DIR          read-only architecture-independent data [PREFIX/share]

new autoconf:
  --prefix=PREFIX         install architecture-independent files in PREFIX
  --datarootdir=DIR      read-only arch.-independent data root [PREFIX/share]
  --datadir=DIR          read-only architecture-independent data [DATAROOTDIR]

The problem is in AM_GLIB_DEFINE_LOCALEDIR from m4macros/glib-gettext.m4 which hardcodes a double shell expansion:
  localedir=`eval echo "${datadir}/locale"`

this results in a config.h with:
    #define GNOMELOCALEDIR "${prefix}/share/locale"
which will obviously break at runtime.

I verified that adding another level of expansion:
    localedir=`eval echo "${localedir}"`
fixes the problem.

This is a really important problem which will hit a lot of apps, and I don't see autoconf reverting this change, nor how to easily fix this.


I suggest the apps should use a $(gnomelocaledir) in their Makefile.am as explained in the documentation of the AC_DEFINE macro, but I don't see how to have a smooth transition nor how to guarantee backward-compatibility.

Bye,
Comment 1 Ben Pfaff 2006-06-04 18:31:10 UTC
This simple stopgap measure will fix the immediate problem, but
it seems to me that the real problem with
AM_GLIB_DEFINE_LOCALEDIR is ignoring the instructions in the
Autoconf documentation.  Here is what the Autoconf manual says:

How Do I `#define' Installation Directories?
============================================

     My program needs library files, installed in `datadir' and
     similar.  If I use
          AC_DEFINE_UNQUOTED([DATADIR], [$datadir],
                             [Define to the read-only architecture-independent
                              data directory.])


     I get
          #define DATADIR "${prefix}/share"

As already explained, this behavior is on purpose, mandated by the GNU
Coding Standards, see *Note Installation Directory Variables::.  There
are several means to achieve a similar goal:

   - Do not use `AC_DEFINE' but use your `Makefile' to pass the actual
     value of `datadir' via compilation flags, see *Note Installation
     Directory Variables::, for the details.

   - This solution can be simplified when compiling a program: you may
     either extend the `CPPFLAGS':

          CPPFLAGS = -DDATADIR=\"$(datadir)\" @CPPFLAGS@

     or create a dedicated header file:

          DISTCLEANFILES = datadir.h
          datadir.h: Makefile
                  echo '#define DATADIR "$(datadir)"' >$@

   - Use `AC_DEFINE' but have `configure' compute the literal value of
     `datadir' and others.  Many people have wrapped macros to automate
     this task.  For instance, the macro `AC_DEFINE_DIR' from the
     Autoconf Macro Archive(1).

     This solution does not conform to the GNU Coding Standards.

   - Note that all the previous solutions hard wire the absolute path to
     these directories in the executables, which is not a good
     property.  You may try to compute the paths relatively to
     `prefix', and try to find `prefix' at runtime, this way your
     package is relocatable.  Some macros are already available to
     address this issue: see `adl_COMPUTE_RELATIVE_PATHS' and
     `adl_COMPUTE_STANDARD_RELATIVE_PATHS' on the Autoconf Macro
     Archive(2).

   ---------- Footnotes ----------

   (1) Autoconf Macro Archive,
<http://www.gnu.org/software/ac-archive/>.

   (2) Autoconf Macro Archive,
<http://www.gnu.org/software/ac-archive/>.
Comment 2 Stepan Kasal 2006-06-05 09:29:41 UTC
An application of the above general advice:
Instead of the AC_DEFINE, add
AM_CPPFLAGS = -DGNOMELOCALEDIR=\"$(datadir)/locale\"
to Makefile.am in each directory where the symbol is needed.

Projects libgsf, goffice, or gnumeric can serve as an example.
Comment 3 Loïc Minier 2006-06-05 15:43:12 UTC
Stepan Kasal suggests in bug 343885 to switch to GNU Gettext and drop glib-gettext.
Comment 4 Christian Persch 2006-06-07 18:17:42 UTC
*** Bug 344162 has been marked as a duplicate of this bug. ***
Comment 5 Dave Vasilevsky 2006-07-19 06:47:38 UTC
Just a note that the new autoconf 2.60 has been released, so more users are going to start seeing this bug.
Comment 6 Stepan Kasal 2006-08-01 19:45:14 UTC
Let me make this clear: the long explanation in Comment #1 implies that AM_GLIB_DEFINE_LOCALEDIR should not exist.

Consequently, the advice in Comment #2 is not a workaround, it is the right fix.
Comment 7 James Henstridge 2006-11-14 22:10:59 UTC
Created attachment 76594 [details] [review]
am-glib-define-localedir-ac2.6.patch

The attached patch should fix the macro, while maintaining compatibility with automake-2.5x.
Comment 8 James Henstridge 2006-11-14 22:11:42 UTC
Confirming bug.
Comment 9 Matthias Clasen 2006-11-15 19:28:23 UTC
2006-11-15  Matthias Clasen  <mclasen@redhat.com>

        * m4macros/glib-gettext.m4: Apply a patch from James
        Henstridge for compatibility with automake 2.60 (#343825)

Comment 10 Loïc Minier 2006-11-16 09:04:49 UTC
Matthias, it's autoconf not automake. ;)

I verified the fix with autoconf 2.60 and 2.59a, thanks.

I suggest deprecating the macro though.  It's still kludgy, contradicts the autoconf recommendations, and wont permit things which are promised by the autotools such as overriding datadir on make install etc.