Subject: Re: Installing via build.sh.
To: mouss <firstname.lastname@example.org>
From: Richard Rauch <email@example.com>
Date: 05/27/2003 16:51:41
On Tue, May 27, 2003 at 05:52:57PM +0200, mouss wrote:
> At 17:17 22/05/2003 -0500, Richard Rauch wrote:
> >I hit an odd problem: I did "./build.sh distribution" and then also "sets",
> >on my fastest machine, then as root on the laptop, over an NFS mount, I
> >attempted to do a "./build.sh install". This failed over a missing "pax"
> >("nbpax"?) binary.
> you might wanna check that the path to obj stuff is the same for the "build
> and the "build install". if you run these on different OS versions (for
> on a 1.6 and 1.6T), then the "build install" will look in a different
> than that used to put objects/bins by "build dist". [I am assuming you're
> using OBJMACHINE and MKOBJDIRS].
I'm letting the build.sh script set these directories automatically. Is
that a bad idea? (Except during install, I used a -T to force the TOOLDIR;
I don't remember if I used it on any build attempts.)
I finally got a build after I did a "make clean" (yes, with make, not
build.sh) and did a complete build with the faster machine---possibly with
the -T option to build.sh.
I assumed that the tooldir stuff was the only thing that would have
to change for different machines and had interleaved building tools
for the faster machine, then while *it* built a distribution, had
the laptop build its own toolset. Since build.sh automatically
puts these in seperate dirs according to OS version, I thought that
that would be okay.
> check /usr/src/tools/obj.$machine/tools.NetBSD-$version-$machine/
> and check the error message to see whether it is looking for nbpax in the
> you actually have.
The errors that I'm getting now are about flist having/not-having files
that exist in the destdir, if memory serves. nbpax problems were
definitely TOOLDIR-related, I think.
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/