Jim Meyering wrote: > > Green, Paul wrote: > > Gentle Coreutils Developers, > > > > I am writing to notify you of an issue that I stumbled across while > > building coreutils-8.12 on the Stratus OpenVOS platform. > > Hi Paul, > > Thanks for the detailed report. > I'm Cc'ing the automake list, since that's > the source of the compile script.
Thanks, and sorry for not digging further to notice this! [snip] > > The src/Makefile does not list copy.o as a dependency of mv.pm > > (Oops), so Make does not rebuild copy.o prior to running the > > link command. > > My src/Makefile and src/Makefile.in do include that dependency, > assuming your EXEEXT is ".pm". > Does your version of that file look different from this? > > am__objects_1 = copy.$(OBJEXT) cp-hash.$(OBJEXT) extent- > scan.$(OBJEXT) > am_mv_OBJECTS = mv.$(OBJEXT) remove.$(OBJEXT) $(am__objects_1) > mv_OBJECTS = $(am_mv_OBJECTS) > ... > mv$(EXEEXT): $(mv_OBJECTS) $(mv_DEPENDENCIES) > $(EXTRA_mv_DEPENDENCIES) Yes, my copy of the generated Makefile looks the same as that. > This is not due to a missing dependency, > but rather that the compile script removes copy.o > in the process of creating ginstall-copy.o. > You can see that by the fact that when you rerun "make" > after the above failure, it does regenerate copy.o. Yes, I now see that. I was mistakenly keying off of the names of the variables in the Makefile. I should have paid more attention to the actual list of dependencies on the link line. Sorry about that! [snip] > I think you're right that making "compile" smarter is the way to go. > It looks like it could be modified to link (or copy) the source file > to some temporary file name, e.g., copy-xYV4aP.c, compile that > to copy-xYV4aP.o, and rename the latter to the destination .o file. > Of course, it would have to remove the temporary file upon termination- > - both irregular and normal. > > This would also resolve the parallel build race whereby two or more > programs using the same object file both compile the same source to > the same object and rename that file to a different destination. > > To the automake folks, is there any reason not to do that? I agree in general. However, as someone whose operating system only recently (2009) started supporting file names longer than 32 characters, I think the compile script has to be careful not to lengthen the name of the source file. I have noticed a trend in recent years to use longer and longer file names. If the compile script can simply replace the original name by a unique generated name of a reasonable length, that would be better, in my view. I'm sure there must still be some operating systems out there that do not support 255-character file names. Thank you for your quick response and guidance. Thanks PG
