From owner-freebsd-hackers  Fri Feb  3 00:22:52 1995
Return-Path: hackers-owner
Received: (from root@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id AAA02421 for hackers-outgoing; Fri, 3 Feb 1995 00:22:52 -0800
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.9/8.6.6) with ESMTP id AAA02415; Fri, 3 Feb 1995 00:22:43 -0800
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id TAA00593; Fri, 3 Feb 1995 19:21:45 +1100
Date: Fri, 3 Feb 1995 19:21:45 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199502030821.TAA00593@godzilla.zeta.org.au>
To: freebsd-bugs@freefall.cdrom.com, freebsd-hackers@freefall.cdrom.com,
        ponds!rivers@dg-rtp.dg.com
Subject: Re: drand48 problems persist.
Sender: hackers-owner@FreeBSD.org
Precedence: bulk

>I know several people have indicated they are unable to reproduce
>my reported problems about drand48 (on FreeBSD 2.0R).
>
>However, I'm unable to get drand48 to work on any machine where 2.0R is
>installed.
>...
>---
>extern double drand48();
>
>main()
>{
>        int i;
>        double d;
>
>        for(i=0;i<3072;i++) {
>          d = drand48();
>          if(d >= 1.0) {
>                printf("%lf is greater than 1.0\n", d);
>          }
>        }
>}

The problem seems to be that the libraries shipped with 2.0R don't match
the sources shipped with 2.0.  Fix: rebuild libc.* and everything that
uses drand48.  Sigh.

The key fix was committed to /usr/src/include/stdlib.h a few hours
before the 2.0R release buy the library apparently wasn't rebuilt to
pick up the changes.  I looked at all the relevant timestamps and got
confused.  The library objects seem to be up to date with
/usr/src/include/stdlib.h.  However, they are out of date with
/usr/include/*.h.  Building /usr/include apparently clobbered all the
timestamps.  There seem to be some timezone bugs in isofs/cd9660 and/or
the cdrom.  All the timestamps on the cdrom seem to be wrong by the time
difference between here and California.

There seems to be a another bug getting the correct paths for shared
libraries.  To test for the drand48 bug, I first tried
`cc -o prog prog.c -L/cdrom/filesys/usr/lib/', but there was no problem
because my current libraries were linked to.  The correct libraries are
linked to iff the -static flag is used.

Bruce