GNU bug report logs - #8616
conflict between build-aux/compile script and coreutils Makefiles

Previous Next

Full log

Message #23 received at 8616 <at> debbugs.gnu.org (full text, mbox):

From: "Green, Paul" <Paul.Green <at> stratus.com>
To: "Jim Meyering" <jim <at> meyering.net>
Cc: 8616 <at> debbugs.gnu.org, automake <at> gnu.org
Subject: RE: bug#8616: conflict between build-aux/compile script and coreutils
	Makefiles
Date: 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!

[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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.