Subject: semi-random pmax file questions
To: Aaron J. Grier <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: port-pmax
Date: 02/04/1998 17:49:39
[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"