In article <199509270848.BAA00633@Reno.Stanford.EDU> jonathan@DSG.Stanford.EDU writes:
>
>>Number:         1528
>>Category:       bin
>>Synopsis:       bsd.lib.mk builds foo.o.o for libc ?
>>Confidential:   no
>>Severity:       non-critical
>>Priority:       medium
>>Responsible:    bin-bug-people (Utility Bug People)
>>State:          open
>>Class:          support
>>Submitter-Id:   net
>>Arrival-Date:   Wed Sep 27 05:05:02 1995
>>Last-Modified:
>>Originator:     Jonathan Stone
>>Organization:
>	Stanford Distributed Systems Group
>>Release:        NetBSD-current supp'ed at 1:40am 27 Sept 1995 PST
>>Environment:
>	
>System: NetBSD Reno.Stanford.EDU 1.0A NetBSD 1.0A (NEWCONF) #596: Tue Sep 26 17:27:54 PDT 1995 jonathan@Reno.Stanford.EDU:/usr/src/sys/arch/pmax/compile/NEWCONF pmax
>
>
>>Description:
>	`make -n libc.a'' in src/lib/libc makes <foo>.o.o and then does ld -r
>	<foo>.o.o -o <foo>.o
>	Which may well produce the desired results, but is, to say
>	the least, disconcerting, and may be an unwanted side-effect of
>	today's fix to /usr/share/mk/bsd.lib.mk.
>
>	This may also break cross-compilation with other make variants,
>	or older versions of Berkeley make, which I think *is* a real concern.
>
>>How-To-Repeat:
>	``(cd /usr/src/lib/libc; make -n -k)''
>	on a suitably out-of-date libc tree.
>e.g:

This was the intended fix. The way it was done before, was that the LD
output was left to go to a.out and then a.out was mv'ed to the target.
This approach does not work for parallel make's where many a.outs get
created in parallel. The .o suffix was chosen, because many c compilers
do not allow you to specify -o to a file without a .o suffix. So yes,
this works on all systems I've tried so far. The way the rules were
done before [cc -c foo.c -o foo.{so,po}] did not work at least in one
popular unix variant...

christos