mrg wrote

> for a long while now, i have regularly built sparc64 both native and
> cross, using the in tree compiler.  if it doesn't work then it is a
> bug that should be reported..

Well, my build just fell over:

| # ./build.sh -O /usr/obj
...
| dependall ===> toolchain
| Configuring for a sparc64-unknown-netbsd1.6A host.
...
| expect 30 shift/reduce conflicts and 42 reduce/reduce conflicts.
| cd /usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc/cp; true  -d -o parse.c parse.y
| cd /usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc/cp; grep '^#define[    ]*YYEMPTY' parse.c >>parse.h
| cd /usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc/objc;  true  -o objc-parse.c objc-parse.y
| gperf -L C -F ', 0, 0' -p -j1 -i 1 -g -o -t -G -N is_reserved_word  -k1,3,$ /usr/src/tools/toolchain/../../gnu/dist/toolchain/gcc/c-parse.gperf >tmp-gperf.h
| gperf: not found
| *** Error code 127
| 
| Stop.
| nbmake: stopped in /usr/obj/tools/toolchain/build/gcc
| *** Error code 1
| 
| Stop.

Now, the OS on there came from what was a week or so ago the most
recent sparc64 snapshot (2002-05-26, I think - which appears to still
be the most recent), and it was one of the snapshots built with the
broken pax.  I can't recall whether gperf was one of the casualties in
that tarball or not.

Is there some way (perhaps akin to the old MKINFO=no sort of thing) to
disable that use of gperf?  Presumably it's _possible_ to build and
install gperf by hand; is it a sane thing to contemplate under the New
Build Order, or would I be better off asking around to see if someone
could send me a gperf executable?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B