Well, make that _at least two people_ who got bit!  :)

Anyway, I was doing a `make build' and got as far as installing the new
libc.so.12.8 and then most everything started failing, usually with a
Segmentation fault and the obligatory core dump.  Fortunately, there was
enough of my system left (ie /sbin/restore was still there, and is linked
-static) so that I could reload libc from a backup tape.

Now, though, a question:  even though the interface to the libc routines
hadn't changed, shouldn't such a fundamental interface between libc and
the kernel have been enough reason to bump the minor version of the
shared library?

On Sun, 22 Dec 1996, Chris G Demetriou wrote:

> So, i goofed: the new stubs that used __syscall()
> (i.e. /usr/src/lib/libc/sys/*.c) didn't work properly on big-endian
> machines.
> 
> If you have a big endian machine, and have updated your source tree
> between the time of this morning's (Dec. 22) sup scan (~4AM PST) and
> the time of tomorrow morning's (Dec. 23) sup scan (same time 8-), then
> you'll need the patch included below to build a working libc.
> 
> If you've not updated yet, i suggest you put it off until after
> tomorrow morning's update.  You can tell if your system has broken
> sources by:
> 
> 	(1) checking for a prototype for __syscall() in
> 	    /usr/include/unistd.h, and
> 
> 	(2) seeing if the sources named in the patch below look like
> 	    the 'old' revisions in the patches.
> 
> If both of those are true, then you might have this problem.
> 
> 
> This shouldn't affect people with little-endian machines.
> 
> 
> *sigh* I'm really sorry about any trouble i may have caused.  This has
> apparently bitten at least one person.  It just wasn't tested on a
> enough range of machines before it was checked in, and I should have
> known better.  (Every once in a while, you do one or six things like
> that, then you fix them and go back to being really cautious... 8-)