On Tue, Dec 2, 2008 at 11:59 AM, Garrett Cooper <[EMAIL PROTECTED]> wrote: > On Mon, Dec 1, 2008 at 10:06 PM, Paul Smith <[EMAIL PROTECTED]> wrote: >> On Mon, 2008-12-01 at 18:51 -0800, Garrett Cooper wrote: >>> Another issue is ncurses and how it does it's echo'ing (see the >>> following line from progs/Makefile.in): >>> >>> transform.h : >>> echo "#define PROG_CAPTOINFO \"$(define_captoinfo)\"" >$@ >>> echo "#define PROG_INFOTOCAP \"$(define_infotocap)\"" >>$@ >>> echo "#define PROG_RESET \"$(define_reset)\"" >>$@ >>> echo "#define PROG_INIT \"$(define_init)\"" >>$@ >>> >>> Under certain conditions this fails (the bugs who reported the >>> internal bug didn't have a clearcut means for reproducing the issue). >> >> I can't see any possible way that this could fail, unless maybe there >> are multiple instances of make trying to create this same file. I don't >> accept the assertion that this is real-life race-condition-prone code. >> >> When this fails, what are the symptoms? Is the transform.h file >> corrupted somehow? In what way? > > I believe that was the case yes, and the problem might have been NFS / > latency related because we do a lot of our development on NFS shares > with a large number of users, and overtaxed systems. > > If that's truly the case, this is more of a bi-product of an NFS level > caching and ordering of messages issue. > > [OT] > Still... if things are going to be rather static like that and not > going to change across compiles, why not just generate the file once > and leave it as-is? > [/OT] > > -Garrett
Sorry -- forgot to mention the symptom. It was compile failures due to atypical missing symbols. -Garrett _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
