mkhaw@teknowledge-vaxc.UUCP (04/17/87)
We are encountering the following problem with our Sun-3s (SunOS 3.2):
One non-fileserver node has ranlib'ed /usr/xwindows/lib/libX*.a
X libraries, but exports /usr for NFS mount.
Other standalone disked nodes NFS mount the above node's
/usr/xwindows directory.
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.
Thanks in advance,
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303don@BRILLIG.UMD.EDU (Don Hopkins) (04/25/87)
Date: 17 Apr 87 16:42:31 GMT
From: teknowledge-vaxc!mkhaw@Unix.SRI.COM (Michael Khaw)
We are encountering the following problem with our Sun-3s (SunOS 3.2):
One non-fileserver node has ranlib'ed /usr/xwindows/lib/libX*.a
X libraries, but exports /usr for NFS mount.
Other standalone disked nodes NFS mount the above node's
/usr/xwindows directory.
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.
Thanks in advance,
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
This happens to me when the Suns disagree about what time it is.
-Don
Make install, not war.
Drop cables, not boudjim@strath-cs.UUCP (04/29/87)
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)!"
mouse@mcgill-vision.UUCP (der Mouse) (05/02/87)
In article <11893@teknowledge-vaxc.ARPA>, mkhaw@teknowledge-vaxc.ARPA (Michael Khaw) writes: > We are encountering the following problem with our Sun-3s (SunOS 3.2): > [ library accessed via nfs mounts produces complaints from ld that it > needs ranlibbing; problem is that the it already has been. ] > 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 Why? Likliest explanation I see is clock skew. Check `date' on both systems; I expect you will find them different by a substantial amount; at least seconds, probably minutes. > (2) if it ought to work at all. I would certainly say it ought to work. Keep the system times close to one another and the problem will most likely go away. I don't know for sure whether Sun provides the 4.3 timed time synchronization daemon (this is *not* the timed that listens on port 37), but I don't think so. It does not take much work to make timed run on Suns; if you can (ie, if you can get 4.3 timed source), do that and it should get rid of the problem for good (timed will keep the system times within ten milliseconds or so of one another). Guy or someone: why *don't* you have timed? Or was my informant (we are still running 3.0, so I can't check now) mistaken, and you really *do* have it? If so, where? - I'd love to be able to tell him it's there! der Mouse (mouse@mcgill-vision.uucp)
dsc@izimbra.CSS.GOV (David S. Comay) (05/08/87)
we have the 4.3 timed working on all our suns (which run 3.2). most of the changes deal with the fact that sun releases before 3.3 didn't support subnets and at least as of 3.2, the popular `select' macros weren't defined in the standard <sys/types.h>. if you are interested in the diffs, let me know. dsc