Re: small Fortran bug

Re: small Fortran bug

[Mike Stump]

> Date: Tue, 30 Jun 1998 09:59:09 -0400 (EDT)
> From: Craig Burley <burley@gnu.org>

> Whoa, how could this happen?  Wasn't stage1 just `mkdir'ed?

No.  I last did a make bootstrap that failed.  stage1 was already
populated.  Think while 1: do cvs update; make && make check; done.
Before you say don't do that, let me say that I've been doing it for 5
years, and I'm not about to stop.  :-)

Re: small Fortran bug

[Craig Burley]

>> Whoa, how could this happen?  Wasn't stage1 just `mkdir'ed?
>
>No.  I last did a make bootstrap that failed.  stage1 was already
>populated.  Think while 1: do cvs update; make && make check; done.
>Before you say don't do that, let me say that I've been doing it for 5
>years, and I'm not about to stop.  :-)

Seems reasonable to me, and after all the work I've done over the
past months making trivia like "make LANGUAGES=c install" work
(i.e. not install or build any g77 stuff), I'm not about the
take up the "well then, don't do that" argument against making
build procedures work seamlessly.  :)

But I'm at a loss to understand the problem.  Again, my only guess
is that, because g77.c is a link, mv'ing it somehow produces a
new entry (filename) that cannot itself be mv'ed over.

Well, pickle my cumberbund, that's exactly the behavior I see
on my RH GNU/Linux 4.2 system!  Here's the screen snapshot:

[craig@deer gnu]$ mkdir duh
[craig@deer gnu]$ cd duh
[craig@deer duh]$ ls
[craig@deer duh]$ ln -s ../egcs-19980628/gcc/gcc.c g77.c
[craig@deer duh]$ ls -l
total 0
lrwxrwxrwx   1 craig    develop        26 Jul  1 07:47 g77.c -> ../egcs-1998062\8/gcc/gcc.c
[craig@deer duh]$ mkdir stage1
[craig@deer duh]$ mv g77.c stage1
[craig@deer duh]$ !ln
ln -s ../egcs-19980628/gcc/gcc.c g77.c
[craig@deer duh]$ mv g77.c stage1
mv: replace `stage1/g77.c', overriding mode 0777? n
[craig@deer duh]$ ls -l stage1
total 0
lrwxrwxrwx   1 craig    develop        26 Jul  1 07:47 g77.c -> ../egcs-1998062\8/gcc/gcc.c
[craig@deer duh]$

And, guess what, I think I've sussed this.

The problem seems to be that the target file already exists *and*
is "normally not writable", in this case because it is a link
to a file in a nonexistant directory.

Seems to me the ideal solution (for not just g77, but any language
in a subdir that makes a similar kind of link to egcs/gcc/gcc.c) is
one of the following:

  1.  Change the link to be to an absolute pathname, so the link
      works regardless of whether it is in the language subdir `x'
      or stageN/`x' or wherever.

  2.  Instead of mv'ing the link to stageN/`x', simply delete it,
      assuming it's not run from that dir (xgcc and others are,
      but g77 isn't during a build).

I prefer #1.  Opinions?

        tq vm, (burley)

Re: small Fortran bug

[Carlo Wood]

| > Date: Tue, 30 Jun 1998 09:59:09 -0400 (EDT)
| > From: Craig Burley <burley@gnu.org>
| 
| > Whoa, how could this happen?  Wasn't stage1 just `mkdir'ed?
| 
| No.  I last did a make bootstrap that failed.  stage1 was already
| populated.  Think while 1: do cvs update; make && make check; done.
| Before you say don't do that, let me say that I've been doing it for 5
| years, and I'm not about to stop.  :-)

This certainly did not work for me.
If I don't do a 'make clean' after a 'cvs update' it does NOT
(always) build correctly with 'make bootstrap' (it even failed when
comparing the two last compiles: I checked it and the cause
was *.o files that aren't rebuild correctly).
My conclusion at the time was that a 'make clean' was needed.

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: small Fortran bug

[Mike Stump]

> Date: Wed, 1 Jul 1998 07:59:43 -0400 (EDT)
> From: Craig Burley <burley@gnu.org>
> To: mrs@wrs.com

> Seems to me the ideal solution (for not just g77, but any language
> in a subdir that makes a similar kind of link to egcs/gcc/gcc.c) is
> one of the following:

>   1.  Change the link to be to an absolute pathname, so the link
>       works regardless of whether it is in the language subdir `x'
>       or stageN/`x' or wherever.

> I prefer #1.  Opinions?

Generally we try and avoid absolute pathnames.  The C++ frontend works
by not having the .c in STAGESTUFF.  If you remove it from there, it
should work also.  Yes, I know that the link would then never be
freshened without a cleaning, but that's not really important I feel.

Re: small Fortran bug

[Craig Burley]

>Generally we try and avoid absolute pathnames.  The C++ frontend works
>by not having the .c in STAGESTUFF.  If you remove it from there, it
>should work also.  Yes, I know that the link would then never be
>freshened without a cleaning, but that's not really important I feel.

If you are willing and able to do that, I'd appreciate it.  I don't
have CVS access, and this seems like a trivial thing to do a bunch
of tedious work for (which is what doing any simple patch amounts
to, given my kermit/telnet setup, for the moment).

If you're also willing to have the f77.stageN targets `rm -f g77.c'
after mv'ing $G77STAGESTUFF, to avoid the not-freshened problem,
I'd appreciate that too!

        tq vm, (burley)

Re: small Fortran bug

[Craig Burley]

>  mv f/*.o f/fini f/stamp-str f/str-*.h f/str-*.j lang-f77 g77.c g77.o g77spec.o g77version.o stage1/f; \
>fi
>mv: replace `stage1/f/g77.c', overriding mode 0777? y
>
>:-( Maybe we should use mv -f?  This could be a bug in an old GNU
>fileutils rm, if no one else sees this problem.

Whoa, how could this happen?  Wasn't stage1 just `mkdir'ed?

Also, FWIW, g77'c is a link, usually a symbolic one (unless the
system doesn't support those, in which case I assume $(LN_S) expands
to just `ln', unless the system doesn't support that, in which
case I assume it expands to `cp', etc.).

Also, though this should certainly be unrelated, I've run into
problems with `patch' creating empty files (in situations where
that is correct, e.g. a patch that deletes a file) with *no*
access.  Haven't filed a bug report about that, and it's unlikely
what you saw was due to that, but I thought I'd mention it.

        tq vm, (burley)

small Fortran bug

[Mike Stump]

  mv f/*.o f/fini f/stamp-str f/str-*.h f/str-*.j lang-f77 g77.c g77.o g77spec.o g77version.o stage1/f; \
fi
mv: replace `stage1/f/g77.c', overriding mode 0777? y

:-( Maybe we should use mv -f?  This could be a bug in an old GNU
fileutils rm, if no one else sees this problem.