[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cache problem
From: |
Ralf Wildenhues |
Subject: |
Re: cache problem |
Date: |
Thu, 16 Oct 2008 22:52:14 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hello Markus,
thanks for the reports.
* Duft Markus wrote on Thu, Oct 16, 2008 at 03:46:51PM CEST:
> >
> > I just noticed, that when i enable a config.cache that is used by more
> > than one package is problematic, when the first on checks for the build
> > system type only, and the second for both build and host system type.
> > This is, because the host system type check uses ac_cv_build_alias,
> > which is set only if build system type (ac_cv_build) is not cached.
> >
> > Now the first package caches the build system type, but not the host
> > system type, and the second package cannot configure, since the call to
> > config.sub misses an argument (since ac_cv_build_alias is used, which
> > is empty, since build system type was cached)...
FWIW, I'm not yet sure whether this is a valid problem. Even if it is,
you should be able to work around it by adding AC_CANONICAL_HOST to the
toplevel configure.ac. But anyway, before discussing validity let's try
to reproduce it:
I haven't been able to do so yet. Here's what I tried. Please modify
the example so that it shows the failure (maybe it only needs different
flags passed to configure?)
# in an otherwise empty directory:
cat >configure.ac <<\EOF
AC_INIT([build-alias-bug], [1])
AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_SUBDIRS([sub1 sub2])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF
echo "SUBDIRS = sub1 sub2" > Makefile.am
mkdir sub1 sub2
cat > sub1/configure.ac <<\EOF
AC_INIT([sub1], [1])
AM_INIT_AUTOMAKE([foreign])
AC_CANONICAL_BUILD
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF
: >sub1/Makefile.am
cat > sub2/configure.ac <<\EOF
AC_INIT(sub2, 1)
AM_INIT_AUTOMAKE([foreign])
AC_CANONICAL_HOST
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF
: > sub2/Makefile.am
autoreconf -vi
./configure --host=i386-pc-freebsd --build=x86-unknown-linux-gnu
make distclean
./configure --host=i386-pc-freebsd
make distclean
./configure --build=x86-unknown-linux-gnu
# end of example
> Another cache problem is with updating the cache file. This seems rather
> unsafe for parallel builds using the same cache file. What about not
> using cat for updating, but writing into a separate file, and moving it
> over the original file (and not checking the mv return code). This way
> the worst that can happen, is that cache values are lost if two
> configure scripts try to update simultaneously - which shouldn't be too
> critical, since they are simply checked again the next time....
I recently posted a patch to do just this. It wasn't applied, one
reason being that we didn't see a way how two configure scripts could be
running simultaneously; with AC_CONFIG_SUBDIRS at least (the GCC tree
uses a different way but uses per-configure cache files). How do you
get two concurrent configure scripts updating the same config.cache file?
Thanks,
Ralf
- cache problem, Duft Markus, 2008/10/16
- RE: cache problem, Duft Markus, 2008/10/16
- Re: cache problem,
Ralf Wildenhues <=
- RE: cache problem, Duft Markus, 2008/10/17
- Re: cache problem, Ralf Wildenhues, 2008/10/17
- RE: cache problem, Duft Markus, 2008/10/17
- Re: cache problem, Ralf Wildenhues, 2008/10/18
- RE: cache problem, Duft Markus, 2008/10/20
- Re: cache problem, Paolo Bonzini, 2008/10/17