Hi.

The ne(4) driver is broken for my laptop's NIC and has been that
way since August or so of 2004.  Currently, it is running a slightly
unhappy mish-mash of NetBSD versions.  I thought that the thing to
do was to take it off of -current and put it on 1.6.x  I finally
set out to do that: I CVS'ed a 1.6.2 tree and ran build.sh to build
tools and a kernel.

The first time, I forgot to explicitly specify building tools and
ran as:

./build.sh -T/raid/0/tools-1.6 -M/raid/0/build-1.6 kernel=odysseus

...which complained about some tool having a more recent version
than the source or some such.  (I didn't think too critically
and just assumed that it was trying to tell me that it was using
the 2.x native tools when it should have been using the 1.6.2
toolchain from source.)

So, I tried again:

./build.sh -T/raid/0/tools-1.6 -M/raid/0/build-1.6 tools

...which produced this output (clipped from near the end,
up to the first "Error code" line):

 /~~~ output

obj ===> regress/usr.bin/sort
(cd /usr/netbsd/1.6/src/tools && /raid/0/tools-1.6/bin/nbmake dependall)
dependall ===> host-mkdep
rm -f host-mkdep
CC=cc CFLAGS=-O LDFLAGS=  sh /usr/netbsd/1.6/src/tools/host-mkdep/configure --cache-file=config.cache
configure: creating cache config.cache
checking for sh... /bin/sh
checking for mawk... no
checking for gawk... gawk
checking for gcc... cc
checking for C compiler default output... configure: error: C compiler cannot create executables
*** Error code 77

 \___ output

...so.  Can I not use build.sh to build 1.6.2 from a 2.x system?

I *really* need to build a custom kernel first (absolutely) because
I have to hack the ne(4) driver, even in 1.6, in order to get on
the network.  (I guess I could take a pre-built ISO, unbundle
it, add source tarballs, re-construct the ISO, and then build
a custom kernel entirely on the laptop...)

Another alternative is to fool around with a -current from around
May or June of last year, I guess...

(Or I could do something gauche like buy another ethernet interface
for the laptop...(^&  But I'm averse to throwing hardware at what
is basically a software problem, especially when the software problem
*should* be easy to fix.)

-- 
  "I probably don't know what I'm talking about."  http://www.olib.org/~rkr/