[file output on mips broken]


>$ gcc hello.c -o hello
>$ file hello
>hello: ELF 32-bit LSB executable, MIPS R3000_BE - invalid byte order, version 1
>$
>
>Is this normal?  invalid byte order?

It's  an egregious bug.

It's ``normal'' in the sense that it happens every time we import a
new version of file(1) into NetBSD.  The definitions of the MIPS-cpu
ELF and ECOFF constants (for both little- and big-endian) are correct
for a big-endian MIPS CPU.

For a little-endian MIPS cpu, the answers file(1) gives are wrong.

My personal guess, and it's just a guess, is that the person who
maintains the database used by file(1) maintains the codes for MIPS
cpus does so on a big-endian machine, and consistently produces
entries that give the correct answers for little-endian binaries on a
big-endian machine, and either doesn't know or doesn't care that the
database is broken for little-endian machines.


Please send (yet another) PR. Don't send it as category port-pmax;
it's not a pmax bug, it's a bug in the encoding of the database used
by file(1).



>I'm also having a heck of a time getting bash to run...  it compiles, but
>upon execution bombs out with "free: Called with unallocated block
>argument".  I know it's probably un-BSD of me, but I don't particularly
>like csh syntax.  I WANT BASH.  :)

Tell it to use the standard libc malloc(), not its own builtin one.
Or link it static with
	make CC="cc -static"