[libvirt] [PATCH] Don't mix relative and absolute paths.

Philipp Hahn hahn at univention.de
Tue Mar 23 16:16:05 UTC 2010


Am Dienstag 23 März 2010 16:32:47 schrieben Sie:
> On 03/23/2010 09:07 AM, Philipp Hahn wrote:
> > autoconf goes to great lengths to calculate a proper MKINSTALLDIRS path,
> Actually, neither autoconf nor automake touches MKINSTALLDIRS; it is all
> provided by gettext.  Did you test with gettext 0.14, automake 1.9.6 and
> autoconf 2.59?

Just to give you some context: We at Univention build our own Linux Enterprise 
Distribution based on Debian, so our source is basically the Debian source 
plus some additional patches. We and Debian are using 
which is the same as http://libvirt.org/sources/libvirt-0.7.7.tar.gz.
Since neither Debian nor we did re-run any auto*-stuff, we still use the 
original "configure*" and Makefile*s.

If you take a look at configure as shipped, you'll file configure already 
calculating MKINSTALLDIRS:

# tar xfzO libvirt_0.7.7.orig.tar.gz libvirt-0.7.7/configure | grep -A2 -B2         
  if test -n "$ac_aux_dir"; then
    case "$ac_aux_dir" in
      /*) MKINSTALLDIRS="$ac_aux_dir/mkinstalldirs" ;;
      *) MKINSTALLDIRS="\$(top_builddir)/$ac_aux_dir/mkinstalldirs" ;;
  if test -z "$MKINSTALLDIRS"; then

My build environment is somehow older and looks like
autoconf        2.61-8.13.200909072244
automake        1:1.10+nogfdl-1.5.200909151702
automake1.7     1.7.9-9.10.200909151713
gettext 0.17-4.17.200909090228
libtool 1.5.26-4.15.200909100942

> > so just export the variable for gettext, but don't overwrite it with a
> > broken path:
> > $(top_builddir) is a relative path, while $ac_aux_dir can be an absolute
> > path.
> That's a true statement.  But doesn't automake/autoconf provide some
> magic to make it track the correct number of ../ components to be
> properly relative through subdirectories?  In other words, what breakage
> are you fixing?

Yes: top_builddir is relative, but ac_aux_dir can be an absolute path, if you 
run "/absolute/path/to/configure" instead of "../../configure".

I currently need this, because I need to build the source multiple times for 
different Python versions (2.4 and 2.5). The autoconf-stuff currently doesn't 
support this, so I need to build the whole source out-of-tree three times 
with different Python versions passed to --with-python=/usr/bin/python2.[45].
Using relative pathes there broke some other stuff, so I decided to use 
absolute paths, which was working fine until I switched from 0.7.6 to 0.7.7.

> https://www.redhat.com/archives/libvir-list/2010-February/msg00873.html
> claimed that we need something here.  Looking at the gettext history,
> here is what gettext used, prior to retiring usage of MKINSTALLDIRS:

Yes, and here you see, that ac_aux_dir must be checked for being either 
absolute or relative:
> -    case "$ac_aux_dir" in
> -      /*) MKINSTALLDIRS="$ac_aux_dir/mkinstalldirs" ;;
> -      *) MKINSTALLDIRS="\$(top_builddir)/$ac_aux_dir/mkinstalldirs" ;;
The current code assumes relative paths all the time and unconditionally 
prefixes ac_aux_dir with top_builddir, which is wrong.

> Maybe the real fix for the problem you seem to be seeing is to repeat
> more of the body of this (now-obsolete) gettext macro, in the case that
> we are still targetting older gettext 0.14.

Maybe you're right and yours is the better fix.
I just had a look at what's already in configure: Since MKINSTALLDIR was 
already calculated correctly before being overwriten by that 
AC_SUBST()-statement, I decided to just remove the false assignment.

Philipp Hahn
Philipp Hahn           Open Source Software Engineer      hahn at univention.de   
Univention GmbH        Linux for Your Business        fon: +49 421 22 232- 0
Mary-Somerville-Str.1  28359 Bremen                   fax: +49 421 22 232-99
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100323/0ef9add4/attachment-0001.sig>

More information about the libvir-list mailing list