Re: Other interesting mips breakage...

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> X server:  the undefined symbol issues seem to have been resolved,
> but now the server complains that it can't load the "int10" module,
> saying that it doesn't exist.

int10 looks to me like an x86ism.  x.org has gotten rather sloppy about
portability recently (as one simple example, I've seen stuff on the
list along lines like "we want to move all rendering into the GPU", as
if every machine can be assumed to have a GPU); it wouldn't surprise me
if this were another example.  Depending on what you want X for, you
might be better off with good old MIT X.

Of course, that's assuming you're willing to supply your own X instead
of just using what NetBSD ships.  If you want to use xsrc X, I have
nothing useful to say here.

> Also what looks like a NULL pointer dereference.

> The 'dig' utility dies with segfault in pthread_getspecific().

> Can't build anything from pkgsrc as the C compiler dies with bus
> error compiling the first real source in "pkgtools/digest".

These remind me of the issues I recently had on next68k - there was a
compiler bug that manifested on 68k in certain rare circumstances which
I ran into.  Perhaps there's something more generically wrong with MIPS
that's behind these?  I'm totally handwaving here, but these do sound
like something more systemic....

> A few things that persist from early 6.99.x days:

Is there any particular reason you want to heatseek?  On second-class
ports, you may get a better (smaller, stabler, faster, etc) system out
of older NetBSD - eg, from before the desupport announcement.  So, if
that is suitable for your purposes....

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