Re: cache problem

2008-11-12 Thread Ralf Wildenhues 
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

2008-10-20 Thread Duft Markus 
> 
> * 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 toolsbox-3-patches $ cd markus
mduft markus $ tar xfz ../buildroot/distfiles/automake-1.9.6.tar.gz 
mduft markus $ tar xfz ../buildroot/distfiles/libtool-1.5.24.tar.gz 
mduft markus $ autoconf --version
autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.

Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
mduft markus $ automake --version
automake (GNU automake) 1.9.6
Written by Tom Tromey <[EMAIL PROTECTED]>.

Copyright 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
mduft markus $ 
mduft markus $ 
mduft markus $ cd automake-1.9.6/
mduft automake-1.9.6 $ ./configure --cache-file=../cache
configure: creating cache ../cache
checking build system type... lib/config.guess: unable to guess system
type

This script, last modified 2005-07-08, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from

[snip]
# NOTE: needed to update config.{guess,sub} to a newer version for
automake's
# configure to recognize interix6.

mduft automake-1.9.6 $ cp
/tools/src/toolsbox-3-patches/root/config.{sub,guess} lib/
mduft automake-1.9.6 $ ./configure --cache-file=../cache
configure: loading cache ../cache
checking build system type... i586-pc-interix6.0
checking for a BSD-compatible install...
/opt/gentoo.system/usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for perl... /opt/gentoo.system/usr/bin/perl
checking for tex... no
checking whether autoconf is installed... yes
checking whether autoconf works... yes
checking whether autoconf is recent enough... yes
checking whether ln works... yes
checking for grep that handles long lines and -e...
/opt/gentoo.system/bin/grep
checking for egrep... /opt/gentoo.system/bin/grep -E
checking for fgrep... /opt/gentoo.system/bin/grep -F
updating cache ../cache
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating lib/Automake/Makefile
config.status: creating lib/Automake/tests/Makefile
config.status: creating lib/Makefile
config.status: creating lib/am/Makefile
config.status: creating m4/Makefile
config.status: creating tests/Makefile
config.status: creating tests/defs
config.status: creating tests/aclocal-1.9
config.status: creating tests/automake-1.9
mduft automake-1.9.6 $ cd ../libtool-1.5.24/
mduft libtool-1.5.24 $ ./bootstrap 
/tools/snapshot/toolsbox-3.7pre.20081017/i586-pc-interix6.0/share/acloca
l/pkg.m4:5: warning: underquoted definition of PKG_CHECK_MODULES
  run info '(automake)Extending aclocal'
  or see
http://sources.redhat.com/automake/automake.html#Extending-aclocal
mduft libtool-1.5.24 $ ./configure --cache-file=../cache 
configure: loading cache ../cache
checking for a BSD-compatible install... (cached)
/opt/gentoo.system/usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... (cached) gawk
checking whether make sets $(MAKE)... (cached) yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking for a sed that does not truncate output...
/tools/snapshot/toolsbox-3.7pre.20081017/i586-pc-interix6.0/bin/sed
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
mduft libtool-1.5.24 $ cat cache
cat: cache: No such file or directory
mduft libtool-1.5.24 $ cat ../cache 
# This file is a shell script that caches the results of configure
# tests run on this system so they can be shared between configure
# scripts and configure

Re: cache problem

2008-10-18 Thread Ralf Wildenhues 
* 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:
.
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

2008-10-17 Thread Olly Betts 
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

2008-10-17 Thread Duft Markus 
> 
> * 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

2008-10-17 Thread Paolo Bonzini 

> 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

2008-10-17 Thread Ralf Wildenhues 
* 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

2008-10-17 Thread Duft Markus 
> 
> 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

2008-10-16 Thread Eric Blake 
-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

Re: cache problem

2008-10-16 Thread Olly Betts 
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

2008-10-16 Thread Ralf Wildenhues 
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

2008-10-16 Thread Duft Markus 
> 
> 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

cache problem

2008-10-16 Thread Duft Markus 
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)...

Hope I made myself clear :) excuse my English...

Cheers, Markus


___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf