This is a discussion on 3.1.3a iso - defective binaries - GNU uname - Minix ; I have found that several of the installed binaries on the 3.1.3a iso image are defective, and recompiling from the sources in /usr/bigsrc corrects the problem. I don't know whether the binaries are out of sync with the sources, or ...
I have found that several of the installed binaries on the 3.1.3a iso image
are defective, and recompiling from the sources in /usr/bigsrc corrects the
I don't know whether the binaries are out of sync with the sources, or they
were simply never compiled and linked with the current libraries. Either
scenario could fit the symptoms. In either case, it should be looked into.
Case in point: GNU uname (/usr/gnu/bin/uname) can only be run by root, or
it crashes with this message: "EMT trap (core dumped)"; and this message
is logged to /dev/console: "PM: unauthorized call of do_getsysinfo by proc
nnnnnnn 'uname'". (This breaks a number of autoconf configure scripts for
packages I've been trying to port.)
The problem goes away if you rebuild uname from the source in
However, the /usr/bigsrc/gnu-coreutils-5.2.1 tree is messed up. If you
follow the instructions in README.MINIX, and try "bigmake all", the build
fails trying to run this command:
$ /bin/sh /usr/home/bin/coreutils-5.2.1/config/missing --run perl -w --
$ ./dircolors.hin > dircolors.h-t
Of course, /usr/home/bin/coreutils-5.2.1/config/missing doesn't exist, so
this doesn't work! This leads me to suspect that the bigsrc tree was never
actually built on the current 3.1.3a system before being dumped into the iso
While we're on the subject, why does the /usr/bigsrc tree belong to user
11275 and group 95, neither of which exists on a newly installed system?
Wouldn't it be appropriate to set their ownership to binperator (as is
done with /usr/src, etc.)?
Would I expect to see a marked improvement if I had packman download all the
packages immediately after installing a new system, rather than using the
ones on the iso image?