This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: (toplevel) introduce host subdir configuration in Makefile
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Nathanael Nerode <neroden at twcny dot rr dot com>, gcc-patches at gcc dot gnu dot org, gdb-patches at sources dot redhat dot com, binutils at sources dot redhat dot com, dj at redhat dot com, autoconf at gnu dot org
- Date: 02 Dec 2002 15:44:21 -0200
- Subject: Re: (toplevel) introduce host subdir configuration in Makefile
- Organization: GCC Team, Red Hat
- References: <20021128221312.GA20889@doctormoo><20021202161822.GA11078@nevyn.them.org><oru1hwml2i.fsf@free.redhat.lsd.ic.unicamp.br><20021202165230.GA12234@nevyn.them.org>
On Dec 2, 2002, Daniel Jacobowitz <drow@mvista.com> wrote:
>> This was a bug in autoconf 2.13, that's fixed in autoconf 2.5x.
> What was? The way files are generated from config.status?
Yup. Each run of config.status uses a different temporary file name.
> Without atomic updates you will definitely lose some updates to the
> cache; since the cache is read once and written once.
Even with atomic updates, you lose some of them, unless the cache is
reread just before it's written back. Currently, configure reads it
when it starts, and rewrites it when it finishes. If you start
multiple configures using the same cache in parallel, the last one to
write its cache out wins, as long as you're not sufficiently unlucky
to have both of them doing it at the same time, in which case you may
end up with a corrupted cache file.
> I'm more worried about two configures writing to the cache at the same
> time. Start both cat processes and you could end up with the two cache
> files interleaved at 1K blocks (or so, depending on FS/OS). That makes
> me really uncomfortable...
Yup, this can be a problem.
The only safe solutions for this at the moment are to use separate
cache files per subdirectory (which defeats most of the purpose of the
cache) or prevent concurrent configure runs (which defeats the point
of making configure parallelizable)
FWIW, we've had target configures running in parallel for a long time,
and I don't know of any corruption caused by this. Granted, there
aren't as many target libraries to be configured as there are host
packages, but still...
One way to try to overcome this limitation in autoconf that has just
occurred to me is to offload the updating of a shared config.cache to
the top-level Makefile. E.g., the Makefile safely copies the
top-level config.cache to a subdirectory before it configures it, and
safely copies it back (or merges it) with the top-level config.cache
when configure finishes. Safety can be accomplished with
cp ${cache_file} subdir/config.cache
run configure in subdir, with --config-cache=./config.cache
mv subdir/config.cache ${cache_file}
trying to merge the contents can get trickier, but I believe it can be
done too.
The one thing we'd have to be careful about is in case the user
specified a config.cache to the top-level, especially /dev/null. We
may have to handle that especially, like autoconf does.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer