This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name)


On Dec 28, 2002, DJ Delorie <dj@delorie.com> wrote:

> Not just update, but *merge*.  Autoconf reads the cache, does lots of
> processing, then writes the cache.  The cache may have been updated
> during the processing, and you don't want to toss those updates.

Why not?  It's just a cache, after all!  Worst case, when you
reconfigure, you get to rerun some tests.  So what?

Also, I've been measuring the size of config.cache in typical
configurations, and I find it to always be about 20Kb for a full
uberbaum build.  The way autoconf updates it is to create a file named
confcache, with the new contents of the cache, and then runs `cat
confcache > $cache_file'.  I believe it is safe to assume that writes
that are this small are atomic on any reasonable OS, and the window
for two or more simultaneous configure scripts to truncate the file at
the same time, and then get a larger write() to complete faster than a
smaller one, such that the smaller write doesn't completely overwrite
the contents of the larger one, is so small that it's negligible.

Just consider that updating config.cache is something that happens,
what, at most 200 times in a full build, with a failure window that
lasts a few microseconds in a process that can take about an hour.

I'm not disputing that it can possibly fail.  I just think the odds
are so low that it's not worth worrying about.  I'd at least like to
be able to control this behavior with configure options.  I'm working
on something that will require configure options to disable the
serialized configurations, but more and more I think we might as well
turn them on by default.  It's not like make -j is default or
anything, and whoever uses make -j might also be expected to configure
with an option that makes the build 100% -j-safe.

> But it would be nice if autoconf managed this problem for us.

It can't.  Consider that the config.cache file specified in the
command line may be in a directory that is not writable, and that two
totally unrelated builds may be using the same config.cache file.  How
could autoconf possibly synchronize them so as to not get in trouble?
To add to the fun, assume that the two configures are running in
separate machines, whose only shared filesystem is the one containing
config.cache, and such that there's no write permission on it anywhere
except in the config.cache file.

Of course, it *might* try to create a lock file in the directory
containing config.cache (but then it might be a soft link elsewhere),
but do you really want to be creating files all over the place that
might be left dangling should the machine reboot?  And then, consider
that configure has really no way to tell something like
--cache-file=/some/random/shared/config.cache from what it gets from
the top-level Makefile, namely --cache-file=../../../config.cache
(which might have been turned into a full, yet possibly non-canonical
pathname such as --cache-file=`pwd`/config.cache).


That said, using some autoconf 2.5x features, we may be able to come
up with a configure-like script whose only purpose is to merge two
config.cache files together, such that we could then try to be smarter
and give each sub-package its own config.cache, just primed with the
global cache and having the global cache updated (mostly)atomically
afterwards.  I say mostly because, if there are other, unrelated
builds using the same global cache file, there's really nothing we can
do to prevent them from conflicting.

-- 
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]