Re: cache problem
Hello Markus, sorry for the long delay. * Duft Markus wrote on Mon, Oct 20, 2008 at 08:48:48AM CEST: * Duft Markus wrote on Fri, Oct 17, 2008 at 09:26:44AM CEST: It happens when: *) configuring automake 1.9.6 with ./configure --cache-file=../cache *) bootstrapping libtool 1.5.24 or 26 with autoconf 2.59 *) configuring libtool with the same cache: ./configure --cache-file=../cache And the error message you are seeing is? (Sorry for not repeating that question last time around, but you should cut and paste both the commands you enter and the output.) Below are the steps to reproduce the problem with automake/libtool: [...] mduft markus $ autoconf --version autoconf (GNU Autoconf) 2.59 mduft markus $ automake --version automake (GNU automake) 1.9.6 checking build system type... (cached) i586-pc-interix6.0 checking host system type... config.sub: missing argument Try `config.sub --help' for more information. configure: error: /bin/sh ./config.sub failed This is a problem with Autoconf 2.59, and has been fixed since. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: cache problem
* Duft Markus wrote on Fri, Oct 17, 2008 at 09:26:44AM CEST: It happens when: *) configuring automake 1.9.6 with ./configure --cache-file=../cache *) bootstrapping libtool 1.5.24 or 26 with autoconf 2.59 *) configuring libtool with the same cache: ./configure --cache-file=../cache And the error message you are seeing is? (Sorry for not repeating that question last time around, but you should cut and paste both the commands you enter and the output.) You also did not state what system this is happening on. Please, Markus, read this text: http://www.catb.org/~esr/faqs/smart-questions.html. It is available in many languages, and contains a lot of very helpful bits that make interaction between users and developers so much easier and less time consuming. And then please provide proof that something is going wrong for you. Also, I posted a recipe for you to try (and modify) so that it exposes the issue. If you could do that, that would be helpful, too; even just trying it out without modifying it would help. It should cost you less than a minute to cut and paste the commands into a shell, and cut and paste the results back. Thanks. So it seems, that this is a problem of older autoconf versions...? That remains to be seen. Whether a bug is already fixed cannot sensibly be judged until it is clear what the bug is. FWIW, I vaguely recall that we fixed some AC_CANONICAL* bug in the last few years, but it could have been a different issue. Cheers, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
RE: cache problem
Hello Markus,
thanks for the reports.
[snip]
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?)
Hehe, the problem occured when using the same cache file for building
autoconf or automake (which both check for build only) and after that
libtool :) so I guess, you have everything you need to reproduce... I
must admit, that I didn't have any look at the configure.{in,ac} files
yet, but you should know them very well anyway.
If that doesn't give a problem for you, I'll be happy trying to
reproduce in a smaller test case...
In the meantime, I work around the issue, by passing --build and --host
all the time, since our build scripts know those anyway, and it doesn't
even cause any more work for me. I just feel, that this is still a
problem, thus I pointed it out...
[snip]
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?
We have a self-written build system which is much like portage, running
on rather powerfull machines with for example 32 CPUs... Our build
system knows how to build as many packages as possible in parallel, so
it is most of the time the case that more than one configure script
runs. It is - more or less - just luck which saved us from failures so
far :) I came across this problem by just thinking about what could
happen when I enable caches for our build system, and reading a little
in a configure script. I havent' (yet) really hit the problem, and don't
even know I could be able to produce it (but I saw another posting about
this already...).
Cheers, Markus
Thanks,
Ralf
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
Re: cache problem
* Duft Markus wrote on Fri, Oct 17, 2008 at 09:00:16AM CEST: 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?) Hehe, the problem occured when using the same cache file for building autoconf or automake (which both check for build only) and after that libtool :) so I guess, you have everything you need to reproduce... Except the exact command lines you used, and the versions of the tools that were used. Please don't leave us guessing. Thanks, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: cache problem
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? The GCC build system runs configure scripts during make (because some of them need that the compiler has already been built). Paolo ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
RE: cache problem
* Duft Markus wrote on Fri, Oct 17, 2008 at 09:00:16AM CEST: 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?) Hehe, the problem occured when using the same cache file for building autoconf or automake (which both check for build only) and after that libtool :) so I guess, you have everything you need to reproduce... Except the exact command lines you used, and the versions of the tools that were used. Please don't leave us guessing. Yeah, sorry, didn't think of that. Trying to reproduce outside our build system, I came to thinking, that this is maybe invalid, since one needs rather old stuff for it (our packages are not quite up to date...) It happens when: *) configuring automake 1.9.6 with ./configure --cache-file=../cache *) bootstrapping libtool 1.5.24 or 26 with autoconf 2.59 *) configuring libtool with the same cache: ./configure --cache-file=../cache So it seems, that this is a problem of older autoconf versions...? Cheers, Markus Thanks, Ralf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: cache problem
On 2008-10-17, Eric Blake [EMAIL PROTECTED] wrote: According to Olly Betts on 10/16/2008 7:40 PM: On 2008-10-16, Ralf Wildenhues [EMAIL PROTECTED] wrote: How do you get two concurrent configure scripts updating the same config.cache file? Open terminal (or screen) windows for two subdirectories of the combined tree and in each modify a file which causes configure to be rerun (e.g. Makefile.am if using automake) and then run make. Well, given that we now have documentation of use case, maybe it's worth revisiting Ralf's patch. Are you comfortable testing it out on top of the current state of the git repository? I'm comfortable, but I'm not sure it would achieve much - I've never actually noticed a problem in practice, even though there's clearly a theoretical problem with the setup I use if the cache file isn't updated atomically. It seems that this would be really hard to actually make happen on demand since you have to get the execution of cat confcache $cache_file near the end of each configure script to overlap in time, and each takes a tiny fraction of a second whereas the rest of the script takes several seconds. Cheers, Olly ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
RE: cache problem
Hi! 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)... 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 Thoughts? Cheers, Markus Hope I made myself clear :) excuse my English... Cheers, Markus ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: cache problem
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 ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: cache problem
On 2008-10-16, Ralf Wildenhues [EMAIL PROTECTED] wrote: How do you get two concurrent configure scripts updating the same config.cache file? Open terminal (or screen) windows for two subdirectories of the combined tree and in each modify a file which causes configure to be rerun (e.g. Makefile.am if using automake) and then run make. (Not a contrived example - this is how I work most of the time. I use the combined tree because we have a bootstrap script which sets things up for testing in tree which is simpler and less error-prone than having to remember to make install on the dependencies of the module you want to test). Cheers, Olly ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
Re: cache problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Olly Betts on 10/16/2008 7:40 PM: Hello Olly, On 2008-10-16, Ralf Wildenhues [EMAIL PROTECTED] wrote: How do you get two concurrent configure scripts updating the same config.cache file? Open terminal (or screen) windows for two subdirectories of the combined tree and in each modify a file which causes configure to be rerun (e.g. Makefile.am if using automake) and then run make. Well, given that we now have documentation of use case, maybe it's worth revisiting Ralf's patch. Are you comfortable testing it out on top of the current state of the git repository? http://lists.gnu.org/archive/html/autoconf-patches/2008-10/msg00018.html - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj38k4ACgkQ84KuGfSFAYBkCQCgt1SBfEaqD6jKdBDUtMkKspQz Wc8AoM7HQytNK67xk4BduB1mi9Grzskf =HU93 -END PGP SIGNATURE- ___ Autoconf mailing list Autoconf@gnu.org http://lists.gnu.org/mailman/listinfo/autoconf
