[Rd] infinite loop in make for src/unix (PR#2477)

John Van Voorhis jvv@cs.umd.edu
Tue Jan 21 02:22:02 2003


----- Original Message -----
From: "Peter Dalgaard BSA" <p.dalgaard@biostat.ku.dk>
Subject: Re: [Rd] infinite loop in make for src/unix (PR#2477)


> jvv@cs.umd.edu writes:
>
> > Full_Name: John Van Voorhis
> > Version: 1.6.2
> > OS: SunOS 5.8
> > Submission from: (NULL) (128.8.130.192)
> >
> >
> > While running initial 'make' everything went fine until src/unix. At
which point
> >
> > it kept entering and exiting src/unix without doing anything. I fixed
the problem
> > by deleting the dependencies on Makefile for the Makedeps and R targets.
> >
> > I am using gnu Make 3.79, gcc 2.95.3, Solaris SunOS5.8 on an UltraSparc.
> >
> > I double checked that I had found the problem by rerunning make with the
> > distributed makefile restored, but the looping behavior did not recur.
> >
> > When I ran make check, everything semed to be OK.
>
> Hmm, I don't see that with Solaris 9 and the same tools. I've seen the
> looping behaviour a couple of times earlier, typically triggered by
> make actions of the type
>
>         for ( i in $SUBDIRS ) ; do cd $i ; make ; done
>
> if one of the cd commands fails silently you end up calling make in the
> current directory...
>
> Could you please see if you can reproduce the effect in a clean
> directory? Notice that to avoid running Sun's make, you need
>
> export MAKE=gmake
> gmake
>
> Also, the shell might play a part so tell us what yours is. And
> whether you are building in the source tree or in a separate build
> directory.
>

gmake has the same looping behavior. When I just run make in the problem
direcrtory, no weird behavior.  And then the top level make runs properly
again with unix built independently.

I think Paul's explanation is probably right:
>I've had this kind of problem (but I don't remember if it was with R) when
my
>workstation and file server's clocks were not syncronized closely enough. I
>think make builds a makefile in src, which is immediately out of date
because of
>the clock skew, but I'm not sure why the workstation clock enters the
>calculation.

I am building on a different machine from the filesystem.