From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 15 04:05:25 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5E810656BD for ; Thu, 15 Jan 2009 04:05:25 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwqsrv02p.mx.bigpond.com (nschwqsrv02p.mx.bigpond.com [61.9.189.234]) by mx1.freebsd.org (Postfix) with ESMTP id 847468FC13 for ; Thu, 15 Jan 2009 04:05:22 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx01p.mx.bigpond.com ([124.188.162.219]) by nschwmtas06p.mx.bigpond.com with ESMTP id <20090115031917.YIVW3101.nschwmtas06p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com> for ; Thu, 15 Jan 2009 03:19:17 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20090115031913.QJDJ6454.nschwotgx01p.mx.bigpond.com@areilly.bpa.nu> for ; Thu, 15 Jan 2009 03:19:13 +0000 Received: (qmail 53221 invoked by uid 501); 15 Jan 2009 03:18:47 -0000 Date: Thu, 15 Jan 2009 14:18:47 +1100 From: Andrew Reilly To: Peter Jeremy Message-ID: <20090115031847.GA52343@duncan.reilly.home> References: <20090114211616.GC16116@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090114211616.GC16116@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.496EAB31.007E,ss=1,fgs=0 Cc: Andrew Hotlab , freebsd-amd64@freebsd.org, freebsd-i386@amd.org, freebsd-arch@freebsd.org Subject: Re: Cross compiling FreeBSD X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2009 04:05:25 -0000 On Thu, Jan 15, 2009 at 08:16:17AM +1100, Peter Jeremy wrote: > This won't work because install{world,kernel} uses programs (under > /usr/obj) that were built to run on the build system (amd64 in > your case) and so won't run on the target (i386) system. > > The supported approach is to NFS mount the target machines onto the > build machine and run "make DESTDIR=/mount/point install{world,kernel}" > on the build machine. Note that this will report errors since NFS > cannot handle UFS flags - you will need to manually remove/add schg flags. Is there any reason (apart from using more space on the build machine) not to install to a DESTDIR (not /) on the build machine, and then tar/pax/cpio that tree across to the client system? Presumably something like that must be done for the distribution builds that go into making the CD and DVD images. NetBSD has (had? it's been a while since I looked) a cool mechanism that allowed the whole tree to be built (and "installed" to a DESTDIR) without root permissions, using a variation on install that copied the file as the running user and recorded the intended user/group/mod/flags in an mtree file. Then a subsequent task created a tarball that contained the file contents and the mtree permissions, all as a non-root user. So you don't even need to muck about with root-over-nfs issues for deployment: just log into the client and untar the distribution over the network (as root). Very, very neat, IMO. I used to build embedded i386 NetBSD installations on my amd64 FreeBSD system that way without much in the way of trouble. Haven't had to do it for a while, though, so perhaps it's all changed. I wouldn't hate to discover that FreeBSD can do that too, though... Cheers, Andrew