bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Build error with binutils 2.18: requires makeinfo but shouldn't


From: Paul Smith
Subject: Build error with binutils 2.18: requires makeinfo but shouldn't
Date: Tue, 17 Jun 2008 22:39:57 -0400

There are some problems with the released tarball for binutils 2.18,
which make it impossible to build unless you have a proper version of
makeinfo installed on your system.  I've seen the problems reported that
a specific version of makeinfo is required, but this bug is not about
that: a correctly constructed GNU package should not require extra tools
like makeinfo in the first place, unless you make some changes to the
documentation etc.  Simply unpacking the tarball and running
configure/make should not require these extra tools.

However, because of the way the binutils tarball has been distributed,
these tools ARE needed.  This is incorrect.


The first problem is that the bfd/elf.c file is much newer (like, 3
weeks newer) than most of the rest of the bfd directory, and in
particular much newer than the bfd/doc/elf.texi file.  If the
distribution was created as it should be, from a pristine checkout of
the CVS tree, this wouldn't be the case since the bfd/doc/elf.texi file
would be constructed from bfd/elf.c with the "chew" utility, and thus
the .texi would be newer, so make would not try to rebuild elf.texi and
then would not decide it needed makeinfo to rebuild bfd.info.  All I can
surmise is that the distributed package was built from a checked out
workspace that had already been used for other builds before; in that
case the move-if-changed script would not have updated the
bfd/doc/elf.texi file if the changes to elf.c didn't result in updates
to elf.texi.

So, the first problem is merely one of process: whenever a new official
release package is created to be uploaded to ftp.gnu.org, you should
always get a brand new, never-built copy of the source and create the
package from that.


Even so, though, this normally would not be a problem because first the
temporary elf.texi file would be built, then move-if-changed would see
that it is not changed and wouldn't move it, and so even then bfd.info
would not need to be rebuilt and makeinfo would not be needed.

However, if you build binutils outside of the source tree this doesn't
work, because of a problem in the bfd/doc/Makefile.am file.  That file
contains rules like this:

elf.texi: chew.c $(srcdir)/../elf.c $(srcdir)/doc.str
        $(MAKE) $(MKDOC)
        ./$(MKDOC) -f $(srcdir)/doc.str <$(srcdir)/../elf.c >elf.tmp
        $(SHELL) $(srcdir)/../../move-if-change elf.tmp elf.texi

Although this rule SEEMS to do things correctly, using $(srcdir) etc.,
it falls down at the last step.  In that step we pass elf.tmp and
elf.texi to move-if-change, but that's not correct because if we are
building outside the source tree, "elf.texi" does not exist!  That file
lives in the $(srcdir).  Because it does not exist, move-if-change
always moves it, of course, and thus it is newer than bfd.info and thus
we always need makeinfo to build binutils.

I think this code needs to be smarter, and first make a copy of the
$(srcdir) version of elf.texi preserving timestamps, then do the
move-if-change.  It may be necessary to discuss this with the folks on
the autoconf lists, to be sure the correct behavior is preserved.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.mad-scientist.us
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist




reply via email to

[Prev in Thread] Current Thread [Next in Thread]