From owner-cvs-sbin Fri Sep 29 14:16:50 1995 Return-Path: owner-cvs-sbin Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA03259 for cvs-sbin-outgoing; Fri, 29 Sep 1995 14:16:50 -0700 Received: from grunt.grondar.za (grunt.grondar.za [196.7.18.129]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id OAA03246 ; Fri, 29 Sep 1995 14:16:23 -0700 Received: from grumble.grondar.za (grumble.grondar.za [196.7.18.130]) by grunt.grondar.za (8.6.12/8.6.9) with ESMTP id XAA15381; Fri, 29 Sep 1995 23:15:55 +0200 Received: from localhost (localhost [127.0.0.1]) by grumble.grondar.za (8.6.12/8.6.9) with SMTP id XAA22975; Fri, 29 Sep 1995 23:15:54 +0200 Message-Id: <199509292115.XAA22975@grumble.grondar.za> X-Authentication-Warning: grumble.grondar.za: Host localhost didn't use HELO protocol To: "Justin T. Gibbs" cc: Mark Murray , "Garrett A. Wollman" , "Andrey A. Chernov" , CVS-commiters@freefall.freebsd.org, cvs-sbin@freefall.freebsd.org Subject: Re: cvs commit: src/sbin Makefile Date: Fri, 29 Sep 1995 23:15:54 +0200 From: Mark Murray Sender: owner-cvs-sbin@FreeBSD.org Precedence: bulk > I don't think this is true anymore. I don't see how having secure > binaries could prevent you from building non-secure binaries. It just > doesn't make any sense. It didn't make sense. It also didn't work. :-( > David complained to me last week about make release not working unless > the libraries are in the chroot tree. Look at release.2: > > release.2: > @cd ${.CURDIR} ; $(MAKE) ckRELEASEDIR > cd ${.CURDIR}/../etc && make distrib-dirs DESTDIR=${RD}/trees/bin > cd ${.CURDIR}/.. ; make distribute DISTDIR=${RD}/trees > cd ${.CURDIR}/../eBones && ( \ > make bootstrap ;\ Sure - these are just putting things in the ${DISTDIR} (or should be - with recent changes it is quite possible that this is broken). > The make bootstrap will fail (or used too until I did the LDADD fixes to > eBones) since the libraries aren't *installed* in the bootstrap target > until after all of eBones is built. I think it was kprop that fell over > first. Ah yes, the LDADD changes. If those are not _correctly_ set to the appropriate ebones/lib/libfoo/obj/ then it will fail. At 2.0.5 release time, this was working. I own up to breaking this when I redid the make files during the Great Repository Copy (tm). > >I agree though that this make system is ropey as hell... > > Yup. :-) -- Mark Murray 46 Harvey Rd, Claremont, Cape Town 7700, South Africa +27 21 61-3768 GMT+0200 Finger mark@grumble.grondar.za for PGP key