From owner-freebsd-current  Tue May 21 12:19:52 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id MAA20574
          for current-outgoing; Tue, 21 May 1996 12:19:52 -0700 (PDT)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id MAA20568
          for <current@FreeBSD.org>; Tue, 21 May 1996 12:19:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.5/8.6.9) with SMTP id MAA02565; Tue, 21 May 1996 12:19:37 -0700 (PDT)
To: Andrew Gallatin <gallatin@stat.Duke.EDU>
cc: current@FreeBSD.org
Subject: Re: NFS v3 problem 
In-reply-to: Your message of "Tue, 21 May 1996 12:13:15 EDT."
             <199605211613.MAA18122@diego.isds.duke.edu> 
Date: Tue, 21 May 1996 12:19:37 -0700
Message-ID: <2563.832706377@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@FreeBSD.org
X-Loop: FreeBSD.org
Precedence: bulk

> I think that I've tracked this down to ar interacting with nfsv3; it
> doesn't seem to matter if the f77 or ranlib steps are run when the fs
> is mounted nfsv2 or nfsv3.  Ranlib will always fail if ar was run on
> an nfsv3 mounted fs, and always succeed if ar was run on an nfsv2
> mounted fs. 
> ...
> If there's anything further I can do to help track this down, I'll be
> happy to help out however I can.  BTW, my system is a Micron

I think the first step is to see what the differences between the v2
and v3 created versions of libblas.a are.  Then you can try and work
backwards to see what ar did to create the corrupt version of libblas
and, in turn, which NFS operation is going awry.

					Jordan