Subject: semi-random pmax file questions
To: Aaron J. Grier <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
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
>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"