BuildError f/g77.info

BuildError f/g77.info

[Clark Evans]

I'm trying ot build from the most recent CVS image, 15:00 17-FEB-1999
to try out the 'java' support!  Unfrortunately, the "make install"
is having problems with the g77.info file.  I don't 
even need fortran, how can i disable building/installing
that module?  I tried --disable-f, and many other permutations.
on the configure line.   

Anyway... here is the bug

if [ -f lang-f77 ]; then \
  rm -f ./f/g77.info-*; \
  /usr/local/src/egcs/egcs/texinfo/makeinfo/makeinfo  -I./f -o f/g77.info ./f/g77.texi; \
else true; fi
Making info file `f/g77.info' from `./f/g77.texi'.
./f/intdoc.texi:10389: Cross reference to nonexistent node `Fdate Intrinsic (subroutine)'.
makeinfo: Removing output file `f/g77.info' due to errors; use --force to preserve.
make[1]: *** [f/g77.info] Error 2
make[1]: Leaving directory `/usr/local/src/egcs/egcs/gcc'
make: *** [install-gcc] Error 2
[root@lucky egcs]# su clark

Re: BuildError f/g77.info

[craig]

Ulrich Drepper fixed this typo.  Thanks again!

I'm a bit nervous as to how this happened -- I *thought* I was being
very careful to make changes in a working (non-CVS) directory,
verify that those changes properly built a new Info doc for g77,
then produce a patch file and apply that to my CVS directory before
committing.

Though, I did run into a merge conflict yesterday morning trying
to commit all those Y2K-related changes.  Perhaps that somehow led
to the trouble.

Anyway, I *usually* test my own stuff before committing it, and will
try to do so more thoroughly in the future.

        tq vm, (burley)

Re: BuildError f/g77.info

[H.J. Lu]

> 
> I'm trying ot build from the most recent CVS image, 15:00 17-FEB-1999
> to try out the 'java' support!  Unfrortunately, the "make install"
> is having problems with the g77.info file.  I don't 
> even need fortran, how can i disable building/installing
> that module?  I tried --disable-f, and many other permutations.
> on the configure line.   
> 
> Anyway... here is the bug

That is a g77 Makefile bug. I meant to fix it. But I don't want
to waste my time on it. I am still waiting for other g77/libf2c
related Makefile patches of mine to be installed. It seems to me
that people working on g77/libf2c either don't care or have few
clues on Makefile. It is not news to me.

If people who maintains g77 Makefile really wants to fix it,
please drop me a line.

Thanks.

H.J.

Re: BuildError f/g77.info

[craig]

>That is a g77 Makefile bug. I meant to fix it. But I don't want
>to waste my time on it. I am still waiting for other g77/libf2c
>related Makefile patches of mine to be installed. It seems to me
>that people working on g77/libf2c either don't care or have few
>clues on Makefile. It is not news to me.
>
>If people who maintains g77 Makefile really wants to fix it,
>please drop me a line.

HJ, perhaps you've forgotten, or somehow missed, my email of
the first of the month on this topic.  It is enclosed below.

In any case, I'll make it *very clear* so you can understand it:

  NEVER, NEVER, NEVER AGAIN post messages claiming that g77 people
  either don't care or don't know about Makefile stuff.  It is a lie,
  and repeating it doesn't make it any more true.

I also asked you, back awhile, to remind me about patches you'd
sent that were pending, at you sent me some pointers to them.
I consider those to still be in my large, but slowly shrinking,
in-box.  (Have you not noticed the sudden, substantial increase
of recent CVS changes to the g77 areas of the repository by myself?
Has it occurred to you how much of a strain my being generally
unavailable for real g77 work during the preceding months has
been on other g77 people, like Dave Love -- the closest thing we
have to a libf2c guru on the egcs list -- and Toon Moene?)

Your patches will not get addressed any faster by continuing to
insult the integrity and the expertise of g77 developers.

Now, I want you to take a moment out of your busy schedule, find a
post-it note, write "STOP INSULTING G77 DEVELOPERS", and stick it
on your video display.  Come to think of it, change "G77" to "GCC",
and make *all* of us happier.

        tq vm, (burley)


>>Date: 1 Feb 1999 12:48:00 -0000
>>From: craig@jcb-sc.com
>>To: hjl@lucon.org
>>CC: egcs@egcs.cygnus.com
>>Cc: craig@jcb-sc.com
>>In-reply-to: <m1073ND-0000V1C@sea.lucon.org> (hjl@lucon.org)
>>Subject: Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1
>>
>>Thanks for the patch-pointers, they're in my email in-box for me to
>>get to someday.
>>
>>>The discussion and inaction around those threads leave me an impression
>>>that noone from libf2c really cares or understands what is going. I am
>>>more than happy to be proved wrong on that.
>>
>>Don't hold yer breath.  :)  I'm sure there's a good amount of *caring*,
>>but time and understanding are in short supply.
>>
>>Remember that libf2c isn't "grown" in these parts -- it's from netlib --
>>so egcs/libf2c is really libg2c, a version of libf2c modified to be
>>generally compatible with libf2c but more appropriate for use with g77
>>than vanilla libf2c.
>>
>>So there's not really any individual developer who works on libf2c as
>>the run-time library for g77, in the same sense that there probably is
>>at least one for glibc, libc5, etc.  That is, the person who best
>>understands libf2c does not work on g77, egcs, gcc2, or anything like
>>that (though he's been generally quite willing to change libf2c to
>>accommodate g77 needs to seem general-purpose enough).
>>
>>Normally, Dave Love takes care of the libU77 part of libg2c (there's
>>no libU77 in libf2c) and all the configury stuff.  I've made changes
>>to the libF77 and, especially, libI77 areas, but I've been out-to-lunch
>>for a couple of months now (at least), which should change soon.
>>
>>Another wrinkle is that we (the g77 people) have been still trying to
>>support FSF-g77 in some fashion, so we avoid making too many changes
>>to egcs-libg2c that can't be directly put in FSF-g77-libg2c.
>>
>>So, things should improve, but I can't promise when or by how much.
>>
>>Someday maybe libg77 -- a run-time library designed to work solely with
>>and for g77 -- will happen.  In one sense, that'll make for more
>>development and maintenance effort overall, but it'll be more monolithic:
>>the problems of coping with different versions of something not really
>>designed for g77 won't be there, so what'll be left will, while larger,
>>will be more straightforward to deal with.
>>
>>        tq vm, (burley)

Re: BuildError f/g77.info

[H.J. Lu]

> Now, I want you to take a moment out of your busy schedule, find a
> post-it note, write "STOP INSULTING G77 DEVELOPERS", and stick it
> on your video display.  Come to think of it, change "G77" to "GCC",
> and make *all* of us happier.
> 

Sorry if you view my comments on g77 as insulting. I didn't mean it.
I appolize here to all g77 peole I have insulted.

Now back to the g77 problem. Do you know why people have problem with
intdoc.texi in g77? It is not a new problem. BTW, I have fed up with
it and fixed it in egcs 1.1.2/Linux. Here is my ChangeLog entry:

Thu Feb 18 09:06:23 1999  H.J. Lu  (hjl@gnu.org)

        * Makefile.in (f77.start.encap): Add $(srcdir)/f/intdoc.texi.

It may not be the best fix. But it works for me.


H.J.

Re: BuildError f/g77.info

[craig]

>Now back to the g77 problem. Do you know why people have problem with
>intdoc.texi in g77? It is not a new problem. BTW, I have fed up with
>it and fixed it in egcs 1.1.2/Linux. Here is my ChangeLog entry:
>
>Thu Feb 18 09:06:23 1999  H.J. Lu  (hjl@gnu.org)
>
>        * Makefile.in (f77.start.encap): Add $(srcdir)/f/intdoc.texi.
>
>It may not be the best fix. But it works for me.

I can't find anything about what start.encap does, except for a
one-liner in gcc/Makefile.in, which I interpret to mean the
above change is rather inappropriate.

I don't know offhand why people have a problem with intdoc.texi,
other than the usual: it's a derived file, shipped with the distribution,
but updated when the files from which it is derived are more recent.
(These include intdoc.in, intrin.def, etc.)

Also, I've not written this down as a to-do item, but I'm going to now:
I believe the other problem is that egcs 1.0 and 1.1 relegate building
the Info docs to the *installation* phase (`make install'), whereas
that should be done as part of the *build* phase.  I'd like this to
be fixed for egcs 1.2, barring evidence that it can't or shouldn't
be done for some reason.

So, perhaps the combination of the problems we typically have shipping
derived files anyway and the problems introduced by trying to build
things during the installation phase has introduced a problem that
happens to be unique to, but not, per se, any particular fault (to
my knowledge) of, the g77 portion of egcs.

I'm in the middle of running a build/test cycle on my fixes for
-fsyntax-only.  When I finish that, I might look into this soon
after, and see if there's a straightforward fix to get the
documentation to build (for bootstrap and straight builds) at
the proper time.

Even if I get it working for egcs 1.2, it doesn't seem like it's
worth putting in egcs 1.1.2, and I don't think your patch is either.
(I say this from the same standpoint: these are not critical bugs, right?
That is, the problems don't result in bad code being generated or
anything like that?)

But if others want to encourage me to try to fix the doc-build
problem in time for 1.1.2, and Jeff and others don't object,
that'd be pretty fine with me!

        tq vm, (burley)

P.S. One of the reasons I've been given to not build *anything* during the
`make install' that follows the `make ...' used to build is that,
sometimes, `make install' is done via local root from an NFS directory
that resulted from a user build but to which local root has no
write access.  I've gone through, probably, two or three cycles
of fixing and then, later, accidentally breaking this in g77 over
the years.  It'd be nice to get it right in egcs.

Re: BuildError f/g77.info

[Jeffrey A Law]

  In message < 19990218201543.29649.qmail@deer >you write:
  > I can't find anything about what start.encap does, except for a
  > one-liner in gcc/Makefile.in, which I interpret to mean the
  > above change is rather inappropriate.
start.encap is historical (and should be put on the to-kill list).  I believe
it was meant to deal with systems where we had to convert libraries from
one object format to another.  hpux7 or hpux8 on the m68ks was probably the
last system that needed this braindamage (and since then I think the GNU
tools have been extended to handle HP's one of a kind a.out variant).

[ snip ]
  > P.S. One of the reasons I've been given to not build *anything* during the
  > `make install' that follows the `make ...' used to build is that,
  > sometimes, `make install' is done via local root from an NFS directory
  > that resulted from a user build but to which local root has no
  > write access.  I've gone through, probably, two or three cycles
  > of fixing and then, later, accidentally breaking this in g77 over
  > the years.  It'd be nice to get it right in egcs.
Agreed.  I've always been of the opinion that "make install" should strictly
be copying files from the build directory to their ultimate destinations.


jeff

Re: BuildError f/g77.info

[Dave Love]

>>>>> "JCB" == Craig Burley <craig@jcb-sc.com> writes:

 >>> Subject: Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[What on earth was this doing in that thread?]

 >>> Thanks for the patch-pointers, they're in my email in-box for me to
 >>> get to someday.
 >>> 
 >>>> The discussion and inaction around those threads leave me an impression
 >>>> that noone from libf2c really cares or understands what is going. I am
 >>>> more than happy to be proved wrong on that.

[Assuming I got the right references] We cared and understood enough
to get one bogus patch backed out and replaced with something that
should DTRT.  If it doesn't work, make a proper bug report.  After
commenting on the second I couldn't be bothered to argue the toss past
someone who won't read the comments or listen to explanations; sorry.
I did make a change locally which will presumably get considered after
the serious outstanding problem with the libf2c build.

Re: BuildError f/g77.info

[H.J. Lu]

> 
> >Now back to the g77 problem. Do you know why people have problem with
> >intdoc.texi in g77? It is not a new problem. BTW, I have fed up with
> >it and fixed it in egcs 1.1.2/Linux. Here is my ChangeLog entry:
> >
> >Thu Feb 18 09:06:23 1999  H.J. Lu  (hjl@gnu.org)
> >
> >        * Makefile.in (f77.start.encap): Add $(srcdir)/f/intdoc.texi.
> >
> >It may not be the best fix. But it works for me.
> 
> I can't find anything about what start.encap does, except for a
> one-liner in gcc/Makefile.in, which I interpret to mean the
> above change is rather inappropriate.
> 

The deal is $(srcdir)/f/intdoc.texi has to be updated before you do
"make install". I don't have the time to find the best way to do it.
I chose it after several tries. As I said, it works for me. That is
all I care.


H.J.

Re: BuildError f/g77.info

[craig]

>The deal is $(srcdir)/f/intdoc.texi has to be updated before you do
>"make install". I don't have the time to find the best way to do it.
>I chose it after several tries. As I said, it works for me. That is
>all I care.

Okay, that sounds like it indeed is the problem I guessed at earlier,
and Jeff Law seems to agree with my proposed (conceptual) fix.

I'll try to work on a patch to solve this pretty soon, at least for
the 1.2 release.  I'd do it now, but am in the middle of two
other tasks: fixing/testing -fsyntax-only, and fixing g77 so it
properly detects conflicts between function invocations and definitions
(in terms of types).

        tq vm, (burley)

Re: BuildError f/g77.info

[Dave Love]

>>>>> Regarding Re: BuildError f/g77.info ; Jeffrey A Law <law@hurl.cygnus.com> adds:

 Jeff> Agreed.  I've always been of the opinion that "make install"
 Jeff> should strictly be copying files from the build directory to
 Jeff> their ultimate destinations.

However, the GNU standard says

`install'
     Compile the program and copy the executables, libraries, and so on
     to the file names where they should reside for actual use.

Perhaps a change in that should be lobbied for?

Re: BuildError f/g77.info

[Jeffrey A Law]

  In message < rzqpv76xmes.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> Regarding Re: BuildError f/g77.info ; Jeffrey A Law <law@hurl.cygnus.
  > com> adds:
  > 
  >  Jeff> Agreed.  I've always been of the opinion that "make install"
  >  Jeff> should strictly be copying files from the build directory to
  >  Jeff> their ultimate destinations.
  > 
  > However, the GNU standard says
  > 
  > `install'
  >      Compile the program and copy the executables, libraries, and so on
  >      to the file names where they should reside for actual use.
Well, the way to make this work in a sane manner is to have "install" depend
on "all" or whatever default target that is traditionally used.

So, when you build, everything builds.  When you install, you just install.

If someone skips the traditional build step and goes directly to the install
step things still work as expected.

jeff

Re: BuildError f/g77.info

[Toon Moene]

Jeffrey A Law wrote:

> Well, the way to make this work in a sane manner is to have "install" depend
> on "all" or whatever default target that is traditionally used.
> 
> So, when you build, everything builds.  When you install, you just install.
> 
> If someone skips the traditional build step and goes directly to the install
> step things still work as expected.

Unless, like me, you build stuff under your own (or another
non-privileged account) and install as root.

Now there's a difference between "make all; su <passw>; make install"
and "su <passwd>; make install".  The first sequence builds the software
as "unprivileged user" wheras the second builds it as root.

This becomes pretty nasty if - afterwards - you think you could just say
"make clean && make all" as an unprivileged joe.

(Or, like me, you think you can get rid of the build directory with an
rm -rf ...)

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: BuildError f/g77.info

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeff> Well, the way to make this work in a sane manner is to have
 Jeff> "install" depend on "all" or whatever default target that is
 Jeff> traditionally used.

That seems to be what's required by the coding standard, but I thought
doing so was what the general complaint was about (not whatever the
specific bug in question here is).  I'm clearly confused...

Re: BuildError f/g77.info

[Jeffrey A Law]

  In message < rzqsobzu2ej.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  Jeff> Well, the way to make this work in a sane manner is to have
  >  Jeff> "install" depend on "all" or whatever default target that is
  >  Jeff> traditionally used.
  > 
  > That seems to be what's required by the coding standard, but I thought
  > doing so was what the general complaint was about (not whatever the
  > specific bug in question here is).  I'm clearly confused...
No, the problem is somewhere we've got a bogon dependency.

It sounded like someone did a "make ...", the thing built.  Then they did a
"make install" and we started trying to build the info files during the
install process -- which failed for some reason or another.

The claim is that those info files should have been built during the 
initial make.

jeff

Re: BuildError f/g77.info

[craig]

>>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:
>
> Jeff> Well, the way to make this work in a sane manner is to have
> Jeff> "install" depend on "all" or whatever default target that is
> Jeff> traditionally used.
>
>That seems to be what's required by the coding standard, but I thought
>doing so was what the general complaint was about (not whatever the
>specific bug in question here is).  I'm clearly confused...

I believe the patch I sent to the list a day or so ago will fix
everything up.  I'm waiting to see if people (e.g. Chill folks)
have problems with it (it moves their .info docs into the ch/
subdir, mainly to avoid a name conflict due to the canonical
front-end-interface naming scheme).  I figure I'll wait until
late Monday to commit it, if nobody complains.

        tq vm, (burley)

Re: BuildError f/g77.info

[Jeffrey A Law]

  In message < 19990221232729.2275.qmail@deer >you write:
  > I believe the patch I sent to the list a day or so ago will fix
  > everything up.  I'm waiting to see if people (e.g. Chill folks)
  > have problems with it (it moves their .info docs into the ch/
  > subdir, mainly to avoid a name conflict due to the canonical
  > front-end-interface naming scheme).  I figure I'll wait until
  > late Monday to commit it, if nobody complains.
Go ahead and commit it.  If the chill info files barf I'll take care of
them.

jeff

Re: BuildError f/g77.info

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeff> The claim is that those info files should have been built
 Jeff> during the initial make.

OK.  I was partly confused by thinking that building Fortran was
actually disabled in the original complaint.

Re: BuildError f/g77.info

[craig]

>There might be a small reason, namely that some gnu coding standards (gnits ?)
>state that documentation installation should be separate from normal 
>installation.

I don't recall reading that, but I don't keep up much with GNU coding
standards these days.  There's no separation of installation of docs
from "make install" -- in egcs, anyway -- in that the docs are installed
along with everything else when performing that step, and I don't
think, offhand, the relevant "subtargets" are documented.

And, I'd *think* it's non-negotiable that anything installed by "make
install" must have been built during the "make" (aka "make all") step
that preceded it (if so).

>Looking thru the Makefiles, I still can see some evidence of that,
>such as the doc target being  separate from the main build, and invoked
>only at the install-info/install stage.

Methinks that was just a bug.  Remember, *building* the Info files
was a New Thing for gcc users when egcs happened, so it can't be
that old.  In gcc2, the .info files are (still, I assume) shipped
with the distribution, already built.  I doubt it was intentional
to push the building of the docs off until "make install" time -- if
so, it seems to be now seen as a bug, due to (for example) wanting
to allow `root' to install after `joeuser' does the build in a
directory to which `root' has no write access.

In essence, this patch of mine fixes egcs to work the way gcc2 always
has (modulo any bugs there, of course): "make install" installs the
Info docs, without having to build them to do it, assuming a successful
"make" has already been completed.

>But it's probably not quite right, unless proper documentation building
>truely requires it, to lump documentation building with normal building
>proper...

If normal installation installs documentation, then normal building
must build it.  That seems obvious enough, because documentation
is not fundamentally different from executables and libraries,
from the point of view of a typical user of a source distribution.

Adding to the complication in egcs is that one document, g77.info,
is built from a .texi file that, in turn, is built from other sources,
including g77 front-end "code", by other g77 "code", which is
compiled and executed...but that .texi file is shipped anyway (I
forget why we do that offhand), so it lives in the *source* directory.

That means, if it is not up-to-date (according to the relevant timestamps),
building the docs triggers writing that .texi file.

And *that* means, if "make install" builds the docs, "make install"
might try to write into the *source* directory for egcs.

Which is something of a hassle, if that source directory is on CD-ROM.

(Fixing egcs seemed easier, to me, than personally upgrading everybody's
CD-ROM to CD-R, etc.  :)

In summary: I believe this problem is solved, at least until it gets
broken again, as of today's version (19990222) of egcs 1.2.  It's
worth testing again, once in a while.

        tq vm, (burley)

Re: BuildError f/g77.info

[craig]

>Now back to the g77 problem. Do you know why people have problem with
>intdoc.texi in g77? It is not a new problem. BTW, I have fed up with
>it and fixed it in egcs 1.1.2/Linux. Here is my ChangeLog entry:
>
>Thu Feb 18 09:06:23 1999  H.J. Lu  (hjl@gnu.org)
>
>        * Makefile.in (f77.start.encap): Add $(srcdir)/f/intdoc.texi.
>
>It may not be the best fix. But it works for me.

I can't find anything about what start.encap does, except for a
one-liner in gcc/Makefile.in, which I interpret to mean the
above change is rather inappropriate.

I don't know offhand why people have a problem with intdoc.texi,
other than the usual: it's a derived file, shipped with the distribution,
but updated when the files from which it is derived are more recent.
(These include intdoc.in, intrin.def, etc.)

Also, I've not written this down as a to-do item, but I'm going to now:
I believe the other problem is that egcs 1.0 and 1.1 relegate building
the Info docs to the *installation* phase (`make install'), whereas
that should be done as part of the *build* phase.  I'd like this to
be fixed for egcs 1.2, barring evidence that it can't or shouldn't
be done for some reason.

So, perhaps the combination of the problems we typically have shipping
derived files anyway and the problems introduced by trying to build
things during the installation phase has introduced a problem that
happens to be unique to, but not, per se, any particular fault (to
my knowledge) of, the g77 portion of egcs.

I'm in the middle of running a build/test cycle on my fixes for
-fsyntax-only.  When I finish that, I might look into this soon
after, and see if there's a straightforward fix to get the
documentation to build (for bootstrap and straight builds) at
the proper time.

Even if I get it working for egcs 1.2, it doesn't seem like it's
worth putting in egcs 1.1.2, and I don't think your patch is either.
(I say this from the same standpoint: these are not critical bugs, right?
That is, the problems don't result in bad code being generated or
anything like that?)

But if others want to encourage me to try to fix the doc-build
problem in time for 1.1.2, and Jeff and others don't object,
that'd be pretty fine with me!

        tq vm, (burley)

P.S. One of the reasons I've been given to not build *anything* during the
`make install' that follows the `make ...' used to build is that,
sometimes, `make install' is done via local root from an NFS directory
that resulted from a user build but to which local root has no
write access.  I've gone through, probably, two or three cycles
of fixing and then, later, accidentally breaking this in g77 over
the years.  It'd be nice to get it right in egcs.

BuildError f/g77.info

[Clark Evans]

I'm trying ot build from the most recent CVS image, 15:00 17-FEB-1999
to try out the 'java' support!  Unfrortunately, the "make install"
is having problems with the g77.info file.  I don't 
even need fortran, how can i disable building/installing
that module?  I tried --disable-f, and many other permutations.
on the configure line.   

Anyway... here is the bug

if [ -f lang-f77 ]; then \
  rm -f ./f/g77.info-*; \
  /usr/local/src/egcs/egcs/texinfo/makeinfo/makeinfo  -I./f -o f/g77.info ./f/g77.texi; \
else true; fi
Making info file `f/g77.info' from `./f/g77.texi'.
./f/intdoc.texi:10389: Cross reference to nonexistent node `Fdate Intrinsic (subroutine)'.
makeinfo: Removing output file `f/g77.info' due to errors; use --force to preserve.
make[1]: *** [f/g77.info] Error 2
make[1]: Leaving directory `/usr/local/src/egcs/egcs/gcc'
make: *** [install-gcc] Error 2
[root@lucky egcs]# su clark

Re: BuildError f/g77.info

[Jeffrey A Law]

  In message < rzqsobzu2ej.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:
  > 
  >  Jeff> Well, the way to make this work in a sane manner is to have
  >  Jeff> "install" depend on "all" or whatever default target that is
  >  Jeff> traditionally used.
  > 
  > That seems to be what's required by the coding standard, but I thought
  > doing so was what the general complaint was about (not whatever the
  > specific bug in question here is).  I'm clearly confused...
No, the problem is somewhere we've got a bogon dependency.

It sounded like someone did a "make ...", the thing built.  Then they did a
"make install" and we started trying to build the info files during the
install process -- which failed for some reason or another.

The claim is that those info files should have been built during the 
initial make.

jeff

Re: BuildError f/g77.info

[Jeffrey A Law]

  In message < 19990221232729.2275.qmail@deer >you write:
  > I believe the patch I sent to the list a day or so ago will fix
  > everything up.  I'm waiting to see if people (e.g. Chill folks)
  > have problems with it (it moves their .info docs into the ch/
  > subdir, mainly to avoid a name conflict due to the canonical
  > front-end-interface naming scheme).  I figure I'll wait until
  > late Monday to commit it, if nobody complains.
Go ahead and commit it.  If the chill info files barf I'll take care of
them.

jeff

Re: BuildError f/g77.info

[craig]

Ulrich Drepper fixed this typo.  Thanks again!

I'm a bit nervous as to how this happened -- I *thought* I was being
very careful to make changes in a working (non-CVS) directory,
verify that those changes properly built a new Info doc for g77,
then produce a patch file and apply that to my CVS directory before
committing.

Though, I did run into a merge conflict yesterday morning trying
to commit all those Y2K-related changes.  Perhaps that somehow led
to the trouble.

Anyway, I *usually* test my own stuff before committing it, and will
try to do so more thoroughly in the future.

        tq vm, (burley)

Re: BuildError f/g77.info

[craig]

>The deal is $(srcdir)/f/intdoc.texi has to be updated before you do
>"make install". I don't have the time to find the best way to do it.
>I chose it after several tries. As I said, it works for me. That is
>all I care.

Okay, that sounds like it indeed is the problem I guessed at earlier,
and Jeff Law seems to agree with my proposed (conceptual) fix.

I'll try to work on a patch to solve this pretty soon, at least for
the 1.2 release.  I'd do it now, but am in the middle of two
other tasks: fixing/testing -fsyntax-only, and fixing g77 so it
properly detects conflicts between function invocations and definitions
(in terms of types).

        tq vm, (burley)

Re: BuildError f/g77.info

[H.J. Lu]

> Now, I want you to take a moment out of your busy schedule, find a
> post-it note, write "STOP INSULTING G77 DEVELOPERS", and stick it
> on your video display.  Come to think of it, change "G77" to "GCC",
> and make *all* of us happier.
> 

Sorry if you view my comments on g77 as insulting. I didn't mean it.
I appolize here to all g77 peole I have insulted.

Now back to the g77 problem. Do you know why people have problem with
intdoc.texi in g77? It is not a new problem. BTW, I have fed up with
it and fixed it in egcs 1.1.2/Linux. Here is my ChangeLog entry:

Thu Feb 18 09:06:23 1999  H.J. Lu  (hjl@gnu.org)

        * Makefile.in (f77.start.encap): Add $(srcdir)/f/intdoc.texi.

It may not be the best fix. But it works for me.


H.J.

Re: BuildError f/g77.info

[craig]

>>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:
>
> Jeff> Well, the way to make this work in a sane manner is to have
> Jeff> "install" depend on "all" or whatever default target that is
> Jeff> traditionally used.
>
>That seems to be what's required by the coding standard, but I thought
>doing so was what the general complaint was about (not whatever the
>specific bug in question here is).  I'm clearly confused...

I believe the patch I sent to the list a day or so ago will fix
everything up.  I'm waiting to see if people (e.g. Chill folks)
have problems with it (it moves their .info docs into the ch/
subdir, mainly to avoid a name conflict due to the canonical
front-end-interface naming scheme).  I figure I'll wait until
late Monday to commit it, if nobody complains.

        tq vm, (burley)

Re: BuildError f/g77.info

[Dave Love]

>>>>> "JCB" == Craig Burley <craig@jcb-sc.com> writes:

 >>> Subject: Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1

[What on earth was this doing in that thread?]

 >>> Thanks for the patch-pointers, they're in my email in-box for me to
 >>> get to someday.
 >>> 
 >>>> The discussion and inaction around those threads leave me an impression
 >>>> that noone from libf2c really cares or understands what is going. I am
 >>>> more than happy to be proved wrong on that.

[Assuming I got the right references] We cared and understood enough
to get one bogus patch backed out and replaced with something that
should DTRT.  If it doesn't work, make a proper bug report.  After
commenting on the second I couldn't be bothered to argue the toss past
someone who won't read the comments or listen to explanations; sorry.
I did make a change locally which will presumably get considered after
the serious outstanding problem with the libf2c build.

Re: BuildError f/g77.info

[H.J. Lu]

> 
> >Now back to the g77 problem. Do you know why people have problem with
> >intdoc.texi in g77? It is not a new problem. BTW, I have fed up with
> >it and fixed it in egcs 1.1.2/Linux. Here is my ChangeLog entry:
> >
> >Thu Feb 18 09:06:23 1999  H.J. Lu  (hjl@gnu.org)
> >
> >        * Makefile.in (f77.start.encap): Add $(srcdir)/f/intdoc.texi.
> >
> >It may not be the best fix. But it works for me.
> 
> I can't find anything about what start.encap does, except for a
> one-liner in gcc/Makefile.in, which I interpret to mean the
> above change is rather inappropriate.
> 

The deal is $(srcdir)/f/intdoc.texi has to be updated before you do
"make install". I don't have the time to find the best way to do it.
I chose it after several tries. As I said, it works for me. That is
all I care.


H.J.

Re: BuildError f/g77.info

[Marc Espie]

In article < 19990218201543.29649.qmail@deer > you write:
>Also, I've not written this down as a to-do item, but I'm going to now:
>I believe the other problem is that egcs 1.0 and 1.1 relegate building
>the Info docs to the *installation* phase (`make install'), whereas
>that should be done as part of the *build* phase.  I'd like this to
>be fixed for egcs 1.2, barring evidence that it can't or shouldn't
>be done for some reason.

There might be a small reason, namely that some gnu coding standards (gnits ?)
state that documentation installation should be separate from normal 
installation.

Looking thru the Makefiles, I still can see some evidence of that,
such as the doc target being  separate from the main build, and invoked
only at the install-info/install stage.

I guess that the specific state of egcs (with make bootstrap) further 
muddles the issue.

I believe it would be a good idea to check thoroughly how other gnu packages
handle the same problem. Maybe the normal `bootstrap targets', as they're
something  of a `all-in-one item', should handle building info as well ?
But it's probably not quite right, unless proper documentation building
truely requires it, to lump documentation building with normal building
proper...

Re: BuildError f/g77.info

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeff> The claim is that those info files should have been built
 Jeff> during the initial make.

OK.  I was partly confused by thinking that building Fortran was
actually disabled in the original complaint.

Re: BuildError f/g77.info

[Jeffrey A Law]

  In message < 19990218201543.29649.qmail@deer >you write:
  > I can't find anything about what start.encap does, except for a
  > one-liner in gcc/Makefile.in, which I interpret to mean the
  > above change is rather inappropriate.
start.encap is historical (and should be put on the to-kill list).  I believe
it was meant to deal with systems where we had to convert libraries from
one object format to another.  hpux7 or hpux8 on the m68ks was probably the
last system that needed this braindamage (and since then I think the GNU
tools have been extended to handle HP's one of a kind a.out variant).

[ snip ]
  > P.S. One of the reasons I've been given to not build *anything* during the
  > `make install' that follows the `make ...' used to build is that,
  > sometimes, `make install' is done via local root from an NFS directory
  > that resulted from a user build but to which local root has no
  > write access.  I've gone through, probably, two or three cycles
  > of fixing and then, later, accidentally breaking this in g77 over
  > the years.  It'd be nice to get it right in egcs.
Agreed.  I've always been of the opinion that "make install" should strictly
be copying files from the build directory to their ultimate destinations.


jeff

Re: BuildError f/g77.info

[Toon Moene]

Jeffrey A Law wrote:

> Well, the way to make this work in a sane manner is to have "install" depend
> on "all" or whatever default target that is traditionally used.
> 
> So, when you build, everything builds.  When you install, you just install.
> 
> If someone skips the traditional build step and goes directly to the install
> step things still work as expected.

Unless, like me, you build stuff under your own (or another
non-privileged account) and install as root.

Now there's a difference between "make all; su <passw>; make install"
and "su <passwd>; make install".  The first sequence builds the software
as "unprivileged user" wheras the second builds it as root.

This becomes pretty nasty if - afterwards - you think you could just say
"make clean && make all" as an unprivileged joe.

(Or, like me, you think you can get rid of the build directory with an
rm -rf ...)

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: fortran@gnu.org; egcs: egcs-bugs@cygnus.com

Re: BuildError f/g77.info

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 Jeff> Well, the way to make this work in a sane manner is to have
 Jeff> "install" depend on "all" or whatever default target that is
 Jeff> traditionally used.

That seems to be what's required by the coding standard, but I thought
doing so was what the general complaint was about (not whatever the
specific bug in question here is).  I'm clearly confused...

Re: BuildError f/g77.info

[H.J. Lu]

> 
> I'm trying ot build from the most recent CVS image, 15:00 17-FEB-1999
> to try out the 'java' support!  Unfrortunately, the "make install"
> is having problems with the g77.info file.  I don't 
> even need fortran, how can i disable building/installing
> that module?  I tried --disable-f, and many other permutations.
> on the configure line.   
> 
> Anyway... here is the bug

That is a g77 Makefile bug. I meant to fix it. But I don't want
to waste my time on it. I am still waiting for other g77/libf2c
related Makefile patches of mine to be installed. It seems to me
that people working on g77/libf2c either don't care or have few
clues on Makefile. It is not news to me.

If people who maintains g77 Makefile really wants to fix it,
please drop me a line.

Thanks.

H.J.

Re: BuildError f/g77.info

[Jeffrey A Law]

  In message < rzqpv76xmes.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> Regarding Re: BuildError f/g77.info ; Jeffrey A Law <law@hurl.cygnus.
  > com> adds:
  > 
  >  Jeff> Agreed.  I've always been of the opinion that "make install"
  >  Jeff> should strictly be copying files from the build directory to
  >  Jeff> their ultimate destinations.
  > 
  > However, the GNU standard says
  > 
  > `install'
  >      Compile the program and copy the executables, libraries, and so on
  >      to the file names where they should reside for actual use.
Well, the way to make this work in a sane manner is to have "install" depend
on "all" or whatever default target that is traditionally used.

So, when you build, everything builds.  When you install, you just install.

If someone skips the traditional build step and goes directly to the install
step things still work as expected.

jeff

Re: BuildError f/g77.info

[craig]

>There might be a small reason, namely that some gnu coding standards (gnits ?)
>state that documentation installation should be separate from normal 
>installation.

I don't recall reading that, but I don't keep up much with GNU coding
standards these days.  There's no separation of installation of docs
from "make install" -- in egcs, anyway -- in that the docs are installed
along with everything else when performing that step, and I don't
think, offhand, the relevant "subtargets" are documented.

And, I'd *think* it's non-negotiable that anything installed by "make
install" must have been built during the "make" (aka "make all") step
that preceded it (if so).

>Looking thru the Makefiles, I still can see some evidence of that,
>such as the doc target being  separate from the main build, and invoked
>only at the install-info/install stage.

Methinks that was just a bug.  Remember, *building* the Info files
was a New Thing for gcc users when egcs happened, so it can't be
that old.  In gcc2, the .info files are (still, I assume) shipped
with the distribution, already built.  I doubt it was intentional
to push the building of the docs off until "make install" time -- if
so, it seems to be now seen as a bug, due to (for example) wanting
to allow `root' to install after `joeuser' does the build in a
directory to which `root' has no write access.

In essence, this patch of mine fixes egcs to work the way gcc2 always
has (modulo any bugs there, of course): "make install" installs the
Info docs, without having to build them to do it, assuming a successful
"make" has already been completed.

>But it's probably not quite right, unless proper documentation building
>truely requires it, to lump documentation building with normal building
>proper...

If normal installation installs documentation, then normal building
must build it.  That seems obvious enough, because documentation
is not fundamentally different from executables and libraries,
from the point of view of a typical user of a source distribution.

Adding to the complication in egcs is that one document, g77.info,
is built from a .texi file that, in turn, is built from other sources,
including g77 front-end "code", by other g77 "code", which is
compiled and executed...but that .texi file is shipped anyway (I
forget why we do that offhand), so it lives in the *source* directory.

That means, if it is not up-to-date (according to the relevant timestamps),
building the docs triggers writing that .texi file.

And *that* means, if "make install" builds the docs, "make install"
might try to write into the *source* directory for egcs.

Which is something of a hassle, if that source directory is on CD-ROM.

(Fixing egcs seemed easier, to me, than personally upgrading everybody's
CD-ROM to CD-R, etc.  :)

In summary: I believe this problem is solved, at least until it gets
broken again, as of today's version (19990222) of egcs 1.2.  It's
worth testing again, once in a while.

        tq vm, (burley)

Re: BuildError f/g77.info

[Dave Love]

>>>>> Regarding Re: BuildError f/g77.info ; Jeffrey A Law <law@hurl.cygnus.com> adds:

 Jeff> Agreed.  I've always been of the opinion that "make install"
 Jeff> should strictly be copying files from the build directory to
 Jeff> their ultimate destinations.

However, the GNU standard says

`install'
     Compile the program and copy the executables, libraries, and so on
     to the file names where they should reside for actual use.

Perhaps a change in that should be lobbied for?

Re: BuildError f/g77.info

[craig]

>That is a g77 Makefile bug. I meant to fix it. But I don't want
>to waste my time on it. I am still waiting for other g77/libf2c
>related Makefile patches of mine to be installed. It seems to me
>that people working on g77/libf2c either don't care or have few
>clues on Makefile. It is not news to me.
>
>If people who maintains g77 Makefile really wants to fix it,
>please drop me a line.

HJ, perhaps you've forgotten, or somehow missed, my email of
the first of the month on this topic.  It is enclosed below.

In any case, I'll make it *very clear* so you can understand it:

  NEVER, NEVER, NEVER AGAIN post messages claiming that g77 people
  either don't care or don't know about Makefile stuff.  It is a lie,
  and repeating it doesn't make it any more true.

I also asked you, back awhile, to remind me about patches you'd
sent that were pending, at you sent me some pointers to them.
I consider those to still be in my large, but slowly shrinking,
in-box.  (Have you not noticed the sudden, substantial increase
of recent CVS changes to the g77 areas of the repository by myself?
Has it occurred to you how much of a strain my being generally
unavailable for real g77 work during the preceding months has
been on other g77 people, like Dave Love -- the closest thing we
have to a libf2c guru on the egcs list -- and Toon Moene?)

Your patches will not get addressed any faster by continuing to
insult the integrity and the expertise of g77 developers.

Now, I want you to take a moment out of your busy schedule, find a
post-it note, write "STOP INSULTING G77 DEVELOPERS", and stick it
on your video display.  Come to think of it, change "G77" to "GCC",
and make *all* of us happier.

        tq vm, (burley)


>>Date: 1 Feb 1999 12:48:00 -0000
>>From: craig@jcb-sc.com
>>To: hjl@lucon.org
>>CC: egcs@egcs.cygnus.com
>>Cc: craig@jcb-sc.com
>>In-reply-to: <m1073ND-0000V1C@sea.lucon.org> (hjl@lucon.org)
>>Subject: Re: multiple definitions of 'xxx keyed to...' in egcs-1.1.1
>>
>>Thanks for the patch-pointers, they're in my email in-box for me to
>>get to someday.
>>
>>>The discussion and inaction around those threads leave me an impression
>>>that noone from libf2c really cares or understands what is going. I am
>>>more than happy to be proved wrong on that.
>>
>>Don't hold yer breath.  :)  I'm sure there's a good amount of *caring*,
>>but time and understanding are in short supply.
>>
>>Remember that libf2c isn't "grown" in these parts -- it's from netlib --
>>so egcs/libf2c is really libg2c, a version of libf2c modified to be
>>generally compatible with libf2c but more appropriate for use with g77
>>than vanilla libf2c.
>>
>>So there's not really any individual developer who works on libf2c as
>>the run-time library for g77, in the same sense that there probably is
>>at least one for glibc, libc5, etc.  That is, the person who best
>>understands libf2c does not work on g77, egcs, gcc2, or anything like
>>that (though he's been generally quite willing to change libf2c to
>>accommodate g77 needs to seem general-purpose enough).
>>
>>Normally, Dave Love takes care of the libU77 part of libg2c (there's
>>no libU77 in libf2c) and all the configury stuff.  I've made changes
>>to the libF77 and, especially, libI77 areas, but I've been out-to-lunch
>>for a couple of months now (at least), which should change soon.
>>
>>Another wrinkle is that we (the g77 people) have been still trying to
>>support FSF-g77 in some fashion, so we avoid making too many changes
>>to egcs-libg2c that can't be directly put in FSF-g77-libg2c.
>>
>>So, things should improve, but I can't promise when or by how much.
>>
>>Someday maybe libg77 -- a run-time library designed to work solely with
>>and for g77 -- will happen.  In one sense, that'll make for more
>>development and maintenance effort overall, but it'll be more monolithic:
>>the problems of coping with different versions of something not really
>>designed for g77 won't be there, so what'll be left will, while larger,
>>will be more straightforward to deal with.
>>
>>        tq vm, (burley)

Re: BuildError f/g77.info

[Dave Love]

>>>>> "Tim" == Tim Prince <N8TM@aol.com> writes:

 Tim> In a message dated 2/17/99 2:32:51 PM Pacific Standard Time,
 Tim> clark@lucky.distributedsystems.com writes:

 Tim> <<  Unfrortunately, the "make install"
 Tim>  is having problems with the g77.info file. >>

 Tim> Several platforms fail in the info sections.  

How is this platform-dependent?

Re: BuildError f/g77.info

[Mike Stump]

> From: Dave Love <d.love@dl.ac.uk>
> Date: 19 Feb 1999 18:45:31 +0000

>  Jeff> Agreed.  I've always been of the opinion that "make install"
>  Jeff> should strictly be copying files from the build directory to
>  Jeff> their ultimate destinations.

> However, the GNU standard says

> `install'
>      Compile the program and copy the executables, libraries, and so on
>      to the file names where they should reside for actual use.

> Perhaps a change in that should be lobbied for?

I see no contradiction, take for example:
 
all: foo
 
install: all
         cp foo /bin/foo
 
foo: foo.o
     gcc -o foo foo.o
 
Here we see that make all builds, and that make install after a make
all, doesn't build, it only ever copies.  Though in general you have a
point, some people's installs don't depend upon all in this fashion.
 
Implicit in the quoted text was the notion that one would always to a
make all before the make install.

Re: BuildError f/g77.info

[N8TM]

In a message dated 2/17/99 2:32:51 PM Pacific Standard Time,
clark@lucky.distributedsystems.com writes:

<<  Unfrortunately, the "make install"
 is having problems with the g77.info file. >>

Several platforms fail in the info sections.  make -k will run past this.

<< I don't 
 even need fortran, how can i disable building/installing
 that module? >>
The documented option --enable-languages produces configure failures in the
library directories "can't make multiple versions".

make LANGUAGES='c c++ gcov...' often works in the sense that it skips some of
the unwanted parts, but it's not fully functional any more.  Another way is to
gzip or otherwise remove unwanted source directories before configure.  I've
found that make LANGUAGES='c c++ f77 gcov objc' builds all the stuff which
testsuite tests.  I know that others differ, that things are intended to work
somewhat different from this.

Re: BuildError f/g77.info

[Mike Stump]

> From: Dave Love <d.love@dl.ac.uk>
> Date: 19 Feb 1999 18:45:31 +0000

>  Jeff> Agreed.  I've always been of the opinion that "make install"
>  Jeff> should strictly be copying files from the build directory to
>  Jeff> their ultimate destinations.

> However, the GNU standard says

> `install'
>      Compile the program and copy the executables, libraries, and so on
>      to the file names where they should reside for actual use.

> Perhaps a change in that should be lobbied for?

I see no contradiction, take for example:
 
all: foo
 
install: all
         cp foo /bin/foo
 
foo: foo.o
     gcc -o foo foo.o
 
Here we see that make all builds, and that make install after a make
all, doesn't build, it only ever copies.  Though in general you have a
point, some people's installs don't depend upon all in this fashion.
 
Implicit in the quoted text was the notion that one would always to a
make all before the make install.

Re: BuildError f/g77.info

[Dave Love]

>>>>> "Tim" == Tim Prince <N8TM@aol.com> writes:

 Tim> In a message dated 2/17/99 2:32:51 PM Pacific Standard Time,
 Tim> clark@lucky.distributedsystems.com writes:

 Tim> <<  Unfrortunately, the "make install"
 Tim>  is having problems with the g77.info file. >>

 Tim> Several platforms fail in the info sections.  

How is this platform-dependent?

Re: BuildError f/g77.info

[N8TM]

In a message dated 2/17/99 2:32:51 PM Pacific Standard Time,
clark@lucky.distributedsystems.com writes:

<<  Unfrortunately, the "make install"
 is having problems with the g77.info file. >>

Several platforms fail in the info sections.  make -k will run past this.

<< I don't 
 even need fortran, how can i disable building/installing
 that module? >>
The documented option --enable-languages produces configure failures in the
library directories "can't make multiple versions".

make LANGUAGES='c c++ gcov...' often works in the sense that it skips some of
the unwanted parts, but it's not fully functional any more.  Another way is to
gzip or otherwise remove unwanted source directories before configure.  I've
found that make LANGUAGES='c c++ f77 gcov objc' builds all the stuff which
testsuite tests.  I know that others differ, that things are intended to work
somewhat different from this.