GNOME Bugzilla – Bug 138538
gnome28 shared-mime-info install fails with clean tree and bootstrap
Last modified: 2004-12-22 21:47:04 UTC
using jhbuild from CVS HEAD Mar 25. after a bootstrap and a tinderbox build using default gnome28 moduleset, shared-mime-info is failing at make install: ************************************************************ 2004-03-30 18:41:57.405 | Installing shared-mime-info ************************************************************ make install Making install in po make[1]: Entering directory `/opt/source/gnome28/shared-mime-info/po' if test -r ".././mkinstalldirs"; then \ .././mkinstalldirs /opt/gnome-2.8/share; \ else \ /bin/sh ../mkinstalldirs /opt/gnome-2.8/share; \ fi ../mkinstalldirs: ../mkinstalldirs: No such file or directory make[1]: *** [install-data-yes] Error 127 make[1]: Leaving directory `/opt/source/gnome28/shared-mime-info/po' make: *** [install-recursive] Error 1 I haven't investigated it yet but it occurs since changing moduleset from gnome26 to gnome28.
From what I can tell, this is actually an intltool bug. Intltool relies on some other package installing the mkinstalldirs program as a side effect. However, automake-1.8 doesn't install it anymore (since it doesn't use it). Intltool should either install mkinstalldirs when "intltoolize" is run, or not rely on the program at all.
If you decide to get rid of the mkinstalldirs dependency in intltool, you might want to swipe part of automake-1.8's mkdirp.m4 macro and stick it in intltool.m4: AC_DEFUN([AM_PROG_MKDIR_P], [if mkdir -p -- . 2>/dev/null; then # Keeping the `.' argument allows $(mkdir_p) to be used without # argument. Indeed, we sometimes output rules like # $(mkdir_p) $(somedir) # where $(somedir) is conditionally defined. # (`test -n '$(somedir)' && $(mkdir_p) $(somedir)' is a more # expensive solution, as it forces Make to start a sub-shell.) mkdir_p='mkdir -p -- .' else # On NextStep and OpenStep, the `mkdir' command does not # recognize any option. It will interpret all options as # directories to create, and then abort because `.' already # exists. for d in ./-p ./--; do test -d $d && rmdir $d done # $(mkinstalldirs) is defined by Automake if mkinstalldirs exists. if test -f "$ac_aux_dir/mkinstalldirs"; then mkdir_p='$(mkinstalldirs)' else mkdir_p='$(install_sh) -d' fi fi AC_SUBST([mkdir_p])]) Obviously, you'd use a different macro/variable name, so as to not get in automake's way.
This also happens building nautilus-media and gaim. Basically any combination of ./po compilation and automake-1.8. I edited bootstrap to pickup 1.8.3 but the result is the same. Should a bug be opened against intltool/gettext on this? I can get around the problem by simple copying mkinstalldirs into the source tree and rebuilding, but I'd rather the problem wasn't there..
Looked into this, and it doesn't appear to be an intltool bug after all, since intltool isn't using mkinstalldirs in any of its code anymore. For shared-mime-info they are using GNU gettext, but not running gettextize or autopoint from the autogen.sh, so since mkinstalldirs isn't checked into CVS, it isn't found at all. This one probably counts as a bug against shared-mime-info (which uses freedesktop.org's bugzilla, iirc). For the other modules, they are using glib-gettextize. Now glib-gettextize installs a makefile using mkinstalldirs without actually installing the file itself. ie. it relies on the side effect of automake installing a mkinstalldirs script, which Automake-1.8 doesn't do.
same problem with gnome26. The error I get is Making install in po make[1]: Entering directory `/opt/cvs/gnome2/shared-mime-info/po' if test -r ".././mkinstalldirs"; then \ .././mkinstalldirs /opt/gnome26/share; \ else \ /bin/sh ../mkinstalldirs /opt/gnome26/share; \ fi ../mkinstalldirs: ../mkinstalldirs: No such file or directory make[1]: *** [install-data-yes] Error 127 make[1]: Leaving directory `/opt/cvs/gnome2/shared-mime-info/po' the work around I have used is to cd /opt/cvs/gnome2/shared-mime-info ln -s /opt/gnome26/share/automake-1.7/mkinstalldirs . This creates the mkinstalldirs the is used in .../po directory. it seems that automake should create this link. (I searched for mkinstalldirs in the build tree and found a lot of it, linked to various versions of automake-xxx/mkinstalldirs. I believe this should be fixed permanently. checked freedesktop.org bugzilla it is already on the list BUG# 576 Opened: 2004-04-30 10:09 Status: NEW
I made a dirty hack to bin/automake-1.8 (a perl script) which calls a new function to copy mkinstalldirs to the {topsrcdir}/ and then continue. It works fine, but it is not a satisfactory solution.
I'm not as sure that this is an intltool bug now. It is the po/Makefile.in.in which is using mkinstalldirs, but not because of intltool's patching. GNU Gettext's scripts will place a copy of mkinstalldirs in the package's root directory, so it functions okay with Automake-1.8 However glib-gettextize doesn't add mkinstalldirs, which means you run into problems with it (with or without intltool). This is handled in bug 132858. As for shared-mime-info, they have checked in the files glib-gettextize into CVS but omitted mkinstalldirs, so suffer from the same problem. This is handled in: http://freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=576 Since shared-mime-info is in another bugzilla, I'll mark this as a dupe of the glib bug. *** This bug has been marked as a duplicate of 132858 ***