-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bruno Haible on 4/10/2009 5:21 PM: > Ralf Wildenhues wrote: >> I would like to veto this patch, and in general the mentality of hacking >> around further away from the root of the problem than is necessary. >> >> How about trying to fix it instead of this? > > You want to know the "root of the problem"? Here it is: The automake generated > Makefile executed the command > > source='unictype/test-categ_Nl.c' object='unictype/test-categ_Nl.o' > libtool=no \ > DEPDIR=.deps depmode=gcc /bin/sh ../build-aux/depcomp \ > gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64 -DHAVE_CONFIG_H \ > -I. -I.. -I. -I. -I.. -I./.. -I../lib -I./../lib -g -O2 -c \ > -o unictype/test-categ_Nl.o unictype/test-categ_Nl.c > > which invokes the command > > gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64 -DHAVE_CONFIG_H \ > -I. -I.. -I. -I. -I.. -I./.. -I../lib -I./../lib -g -O2 -c \ > -o unictype/test-categ_Nl.o unictype/test-categ_Nl.c \ > -Wp,-MD,unictype/.deps/test-categ_Nl.TPo
It looks like there is a bug in depcomp (or maybe in gcc) for not doing atomic rewrite of a file - a data race is available where the file is large enough to be interleaved from two processes both trying to write dependency files. Are we sure we can't rule out a depcomp fix (or at least a workaround in depcomp), rather than having to resort to documentation? I'm not opposed to the patch, per se, but would like to ensure that we have pushed on the upstream tools building the .Tpo file to make sure it isn't a more substantial bug that we should be fixing first. - -- 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 iEYEARECAAYFAknf6S8ACgkQ84KuGfSFAYDQGwCfVvwH7ayEocM/u8hn4Q3qg2uy EZ8An3f3n+ns9MgTmUfeqhThEwNPJmp1 =oIbF -----END PGP SIGNATURE-----
