[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: bug#8616: conflict between build-aux/compile script and coreutils Ma
RE: bug#8616: conflict between build-aux/compile script and coreutils Makefiles
Thu, 5 May 2011 11:18:21 -0400
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!
> > 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-
> am_mv_OBJECTS = mv.$(OBJEXT) remove.$(OBJEXT) $(am__objects_1)
> mv_OBJECTS = $(am_mv_OBJECTS)
> mv$(EXEEXT): $(mv_OBJECTS) $(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!
> 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
> - 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
Thank you for your quick response and guidance.