From owner-freebsd-commit  Thu Feb  1 19:09:39 1996
Return-Path: owner-commit
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA25978
          for freebsd-commit-outgoing; Thu, 1 Feb 1996 19:09:39 -0800 (PST)
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA25965
          for cvs-all-outgoing; Thu, 1 Feb 1996 19:09:33 -0800 (PST)
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id TAA25955
          for cvs-lib-outgoing; Thu, 1 Feb 1996 19:09:29 -0800 (PST)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id TAA25903
          Thu, 1 Feb 1996 19:08:36 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id NAA23300; Fri, 2 Feb 1996 13:57:55 +1100
Date: Fri, 2 Feb 1996 13:57:55 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199602020257.NAA23300@godzilla.zeta.org.au>
To: jdp@polstra.com, peter@jhome.dialix.com
Subject: Re: cvs commit: src/lib/csu/i386 crt0.c
Cc: CVS-committers@FreeBSD.org, cvs-lib@FreeBSD.org, nate@sri.MT.net
Sender: owner-commit@FreeBSD.org
Precedence: bulk

>> >> I think this will solve the problem...
>> >
>> >I think it will, too.  But, why do you want to solve the problem by
>> >adding 4 lines to the Makefile, when you could solve it instead by
>> >removing 2 lines??
>> 
>> The only thing I was wondering about was if anything in "lib" had
>> c++t0.o linked into it...  It doesn't look like it, but it nearly was
>> a while ago...

>Anyway, now I agree that we should use your solution in the top-level
>Makefile, and not mine.

I prefer John's solution together with fixing what it breaks.

csu is built first to incorrectly fix `make world -DCLOBBER'.  See the
log for rev.1.28.  The problem was that -DCLOBBER blows away the used
library file crt0.o although it preserves the used library files
`*.s[ao].*'.  If DESTDIR isn't set, then building and installing crt0.o
early results in the build utilities being linked with the _new_ crt0.o
and the _old_ shared libraries (or the link failing if someone sets
NOSHARED globally).

Better quick fixes for this problem include:
- don't remove any library files.  Little would be lost, because the
  critical shared libraries aren't removed, so links that should fail
  because the appropriate new library hasn't been installed may bogusly
  succeed using an old shared library, and garbage shared libraries
  aren't removed, so -DCLOBBER's main purpose of removing junk is
  half defeated.
- don't remove any library files if ${DESTDIR}==""; otherwise remove
  all library files.
- remove all library files except those required to link and run the
  build utilities.

Bruce