* Re: small Fortran bug
@ 1998-06-30 19:49 Mike Stump
1998-07-01 6:44 ` Craig Burley
1998-07-02 5:34 ` Carlo Wood
0 siblings, 2 replies; 7+ messages in thread
From: Mike Stump @ 1998-06-30 19:49 UTC (permalink / raw)
To: burley; +Cc: egcs
> 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. :-)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: small Fortran bug
1998-06-30 19:49 small Fortran bug Mike Stump
@ 1998-07-01 6:44 ` Craig Burley
1998-07-02 5:34 ` Carlo Wood
1 sibling, 0 replies; 7+ messages in thread
From: Craig Burley @ 1998-07-01 6:44 UTC (permalink / raw)
To: mrs; +Cc: egcs
>> 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)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: small Fortran bug
1998-06-30 19:49 small Fortran bug Mike Stump
1998-07-01 6:44 ` Craig Burley
@ 1998-07-02 5:34 ` Carlo Wood
1 sibling, 0 replies; 7+ messages in thread
From: Carlo Wood @ 1998-07-02 5:34 UTC (permalink / raw)
To: Mike Stump; +Cc: egcs
| > 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>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: small Fortran bug
@ 1998-07-01 20:15 Mike Stump
1998-07-01 17:13 ` Craig Burley
0 siblings, 1 reply; 7+ messages in thread
From: Mike Stump @ 1998-07-01 20:15 UTC (permalink / raw)
To: burley; +Cc: egcs
> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: small Fortran bug
1998-07-01 20:15 Mike Stump
@ 1998-07-01 17:13 ` Craig Burley
0 siblings, 0 replies; 7+ messages in thread
From: Craig Burley @ 1998-07-01 17:13 UTC (permalink / raw)
To: mrs; +Cc: egcs
>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)
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: small Fortran bug
1998-06-29 19:00 Mike Stump
@ 1998-06-30 6:59 ` Craig Burley
0 siblings, 0 replies; 7+ messages in thread
From: Craig Burley @ 1998-06-30 6:59 UTC (permalink / raw)
To: mrs; +Cc: 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)
^ permalink raw reply [flat|nested] 7+ messages in thread
* small Fortran bug
@ 1998-06-29 19:00 Mike Stump
1998-06-30 6:59 ` Craig Burley
0 siblings, 1 reply; 7+ messages in thread
From: Mike Stump @ 1998-06-29 19:00 UTC (permalink / raw)
To: egcs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~1998-07-02 5:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-06-30 19:49 small Fortran bug Mike Stump
1998-07-01 6:44 ` Craig Burley
1998-07-02 5:34 ` Carlo Wood
-- strict thread matches above, loose matches on Subject: below --
1998-07-01 20:15 Mike Stump
1998-07-01 17:13 ` Craig Burley
1998-06-29 19:00 Mike Stump
1998-06-30 6:59 ` Craig Burley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).