Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!ukc!dcl-cs!strath-cs!jim
From: jim@strath-cs.UUCP
Newsgroups: comp.windows.x
Subject: Re: Sun, "ld", NFS and ranlib
Message-ID: <582@stracs.cs.strath.ac.uk>
Date: Wed, 29-Apr-87 08:25:03 EDT
Article-I.D.: stracs.582
Posted: Wed Apr 29 08:25:03 1987
Date-Received: Fri, 1-May-87 06:53:28 EDT
References: <11893@teknowledge-vaxc.ARPA> <8704251844.AA05398@brillig.umd.edu>
Reply-To: jim@cs.strath.ac.uk
Distribution: world
Organization: Comp. Sci. Dept., Strathclyde Univ., Scotland.
Lines: 43

In article <8704251844.AA05398@brillig.umd.edu> don@BRILLIG.UMD.EDU (Don Hopkins) writes:
>   Date: 17 Apr 87 16:42:31 GMT
>   From: teknowledge-vaxc!mkhaw@Unix.SRI.COM  (Michael Khaw)
>
>	   When someone tries to compile and link a program that uses
>	   the NFS mounted X libraries, "ld" complains that they need
>	   to be ranlib'ed.
>
>   The workaround we're using is to make local (i.e., non-NFS mounted) copies
>   of the X libraries and ranlib them locally.  However, I still want to know
>   (1) why it doesn't work for NFS mounted directories, and (2) if it ought to
>   work at all.
>
>This happens to me when the Suns disagree about what time it is.

The answer to this one lies in a time skew between the NFS client and server
(ie the two machines have a different idea of what the time is). Inside a
ranlib'ed library is a header that contains the date that ranlib was last
run on the library. If this date is older than the date the library was last
modified (stored in the file's inode), ld complains since it thinks that the
library has been updated and the table of contents as supplied by ranlib
hasn't.

Sun have kludged this, but it should still be possible to upset NFS clients
if the library was ranlib'ed from a client (getting the client's time in the
header but the server's time in the inode).

I suggest you ranlib the libraries on the NFS server to resynchronise the
inode and library header. Then try to keep the same time on the server(s)
and client(s). Don't forget setting the timezone when configuring the kernels!
Sun supply a time daemon to keep the same time of day on machines. Perhaps
this isn't running or has been set up on a system that thinks it lives in
a different timezone from the rest?

If you do this, it should all work OK. It does for us with our libraries.

		Jim

ARPA:	jim%cs.strath.ac.uk@ucl-cs.arpa, jim@cs.strath.ac.uk
UUCP:	jim@strath-cs.uucp, ...!seismo!mcvax!ukc!strath-cs!jim
JANET:	jim@uk.ac.strath.cs

"JANET domain ordering is swapped around so's there'd be some use for rev(1)!"