Features Download
From: Keith Marshall <keithmarshall-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f <at> public.gmane.org>
Subject: Re: Ready to build g77 for Vista
Newsgroups: gmane.comp.gnu.mingw.user
Date: Friday 4th January 2008 15:41:21 UTC (over 10 years ago)
On Thu, 2008-01-03 at 16:09 -0500, NightStrike wrote:
> On 1/3/08, Keith Marshall
> > On Thu, 2008-01-03 at 18:01 +0100, Michael Gerdau wrote:
> > > Am Donnerstag, 3. Januar 2008 schrieb Sisyphus:
> > > > Thank you Michael.
> > > >
> > > > make[3]: Entering directory
> > > >
> > > > /home/rob/tmp/mingw-3.4.5/binutils-2.17.50-20060824-1-src/missing
> > > > makeinfo --split-size=5000000 --split-size=5000000 --no-split
-I../../etc -o
> > > > standards.info ../../etc/standards.texi
> > > > WARNING: `makeinfo' is missing on your system.  You should only
need it if
> > > >          you modified a `.texi' or `.texinfo' file, or any other
> > > >          indirectly affecting the aspect of the manual.  The
> > > >          call might also be the consequence of using a buggy `make'
> > > >          DU, IRIX).  You might want to install the `Texinfo'
package or
> > > >          the `GNU make' package.  Grab either from any GNU archive
> > >
> > > You have installed the texinfo package on your machine, haven't
> > > you ?
> > > [makeinfo is part of the texinfo package]
> > > If so, which version ?
> > > [makeinfo --version]
> > >
> > > If it is makeinfo 4.10 (or 4.11) you may have to look at
> > > http://sourceware.org/ml/src-cvs/2007-q4/msg00010.html
> >
> > Notwithstanding that it is useful to have texinfo installed on any
> > host used for development work, this still begs the question: `why
> > is it needed in this case?'  It should not be, and this surely
> > indicates a packaging bug.
> I think you're supposed to remove the bfd.info directory if you don't
> want to build it..  not sure, though.

I don't think so.  In the tarball I have, bfd.info is a *file*, not a
directory.  How would removing one file, which would have been generated
by makeinfo in the first instance, remove a dependency on makeinfo for
generating other *independent* info files?

Even if such a crude workaround did work, it certainly isn't any sort of
solution; another non-solution workaround, which could be considered, is
to simply touch empty copies of all the info files which are expected to
be generated.

FTR, makeinfo is the info documentation compiler; it compiles the binary
format files, which may be interpreted by the info reader, from the text
format of the corresponding texinfo source files.  It is not uncommon
for development snapshot tarballs to provide only the texinfo sources,
and to omit the compiled info files; thus, users who build from such
tarballs need to have makeinfo installed.  However, any GCS conforming
*distribution* tarball is *required* to include the compiled info files,
so that end users installing from source do not require makeinfo.

BTW, the same stipulation is made in respect of lex and/or yacc source
files; development snapshots often provide only the sources, but again,
a distribution tarball is required to include the generated files, so
that the end user is not required to install lex/flex or yacc/bison.

Now, it would seem that our so-called distribution tarballs for the
binutils, and maybe also the GCC sources are, in fact, nothing of the
sort, but are in reality development snapshots; to build from them, the
user must have lex/flex, yacc/bison, and makeinfo installed.  I noted
the first two, in the README file which accompanies the cross-compiler
build script, but I overlooked the third, (because I already had
makeinfo installed before my first build attempt, but did not have
either of the others).  So, while simply installing texinfo, (hence
makeinfo), is also an effective work around for this problem, (subject
to the broken version check in the binutils configure script being
patched), I think we really should provide proper distribution tarballs
in the first place.  For any GCS conforming package, that should require
no more than a `make dist' in a configured development tree, to generate
the corresponding source tarball for distribution.  Unfortunately, GNU
binutils is broken, in the sense that it fails to comply with this GNU
Coding Standard stipulation:--

  $ make dist
  Building a full distribution of this tree isn't done
  via 'make dist'.  Check out the etc/ subdirectory

and alas, I see no obvious clues in the etc/ directory, as to how to
proceed :-(  However, it seems likely that something along the following
lines could have the desired effect:--

  $ rm -rf tmpdir
  $ mkdir -p tmpdir/kit
  $ cd tmpdir
  $ tar xzf $PACKAGE_DIR/binutils-2.17.50-20060117-1-src.tar.gz
  $ find binutils* -type d -name CVS -exec rm -rf {} \;
  $ cd kit
  $ ../binutils*/configure --target=i386-mingw32
  $ make
  $ make distclean
  $ tar chf - . | ( cd ../binutils* ; tar xf - )
  $ cd ..
  $ mv binutils* binutils-2.17.50-mingw
  $ tar czhf binutils-2.17.50-mingw-src.tar.gz binutils*

FWIW, I have tried this: after proceeding as above, I can reproduce the
failure with the original package by:--

  $ su -c 'chmod -x `which makeinfo`'

and then repeating the build from a freshly unpacked copy of the
*original* tarball, to see the OP's reported error.  Subsequently, a
further build form an unpacked copy of the *newly* *created* tarball
does appear to complete successfully, without requiring makeinfo.

> To be more accurate, why does the 'src/missing makeinfo' command that
> the build package uses when this condition hits not work at all?

It does work, exactly as intended.  Its purpose is to tell you that you
need to install texinfo, to be able to build from the source tarball you
are using, and that is precisely what it does.

> What's the point in falling back to a broken implementation?

It isn't a fallback scenario; it's simply a diagnostic aid, telling you
how to circumvent the problem.

Of course, it could be argued that compiling documentation files is
hardly critical to the overall package build; therefore, this omission
could be handled more gracefully, without aborting the build, but that's
an issue for the original package developers to address.


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
MinGW-users mailing list
[email protected]

You may change your MinGW Account Options or unsubscribe at:
CD: 3ms