I pulled over the latest binary snapshots (for the SPARC, though I
suspect it doesn't matter) and replaced my previous binary system.
Upon rebooting, I discovered that all my old executables now printed
"No ld.so" and died; this puzzles me because the compiled-in path to
ld.so in the old binaries is /usr/libexec/ld.so (verified with
"strings - oldbinary | egrep ld.so"), which is the same as the path
found the same way in a new executable (and the same as the path in
-current src/lib/csu/sparc/crt0.c as of an evening or two ago) - though
/usr/libexec/ld.so does not exist, so I'm not sure what's going on.
But relinking cures it, so it's not important, just odd.

More important is something make does.  I have a Makefile that reads,
in part,

abspath.prs.fsm.c: abspath.prs.fsm
	fsm < abspath.prs.fsm > abspath.prs.fsm.c
abspath.cpt.fsm.c: abspath.cpt.fsm
	fsm < abspath.cpt.fsm > abspath.cpt.fsm.c

For the sake of brevity below, I will write "foo" to mean either
"abspath.prs.fsm" or "abspath.cpt.fsm", depending.  Thus, we can think
of the Makefile as containing

foo.c: foo
	fsm < foo > foo.c

On 4.3 (pre-Reno, pre-Tahoe - the old stuff), this worked fine; it
obeyed what I wrote, running "fsm < foo > foo.c" exactly when foo was
newer than foo.c.  SunOS 3.5 make produced a cryptic message "$!
nulled, predecessor circle" and otherwise behaved the same.  SunOS 4.x
make exhibits catastrophic misbehavior; it complains that either "foo
depends on itself" or "foo.c depends on itself" and then either
executes the command given or runs "cc foo.c -o foo", thereby
destroying the input file.  (Successive runs alternate between the two
behaviors; I think the messages alternate too but I'm not sure.)

The make binary in the previous SPARC snapshot worked fine; it did what
the Makefile says to do and didn't get upset.  The current make says
"Graph cycles through foo.c" and treats this as a failure for the
targets that depend on those files.  (Mercifully, it doesn't try to run
"cc -o foo foo.c", but it doesn't execute the specified command either,
and it treats it as a build error, which makes it hard to work around
it by carefully touching the appropriate files.)

How can I teach make to do what I tell it to?  Default rules are all
very well in the absence of explicit instructions to the contrary, but
when (as here) there _are_ explicit instructions, I maintain they
should be obeyed.  I'm prepared to dive into make if I have to to fix
this, but since someone must have added something that caused this
relatively recently, it seems a bit silly for me to go looking de novo.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu

------------------------------------------------------------------------------