A/UX concerns

[Kent Sandvik]

In article <1991Feb22.175718.6395 at agate.berkeley.edu> lindahl at violet.berkeley.edu (Ken Lindahl   642-0866) writes:
>In article <1991Feb21.202509.11608 at ni.umd.edu> steveg at ni.umd.edu (Steve Green) writes:
>    I work with several other programmers on an X windows application that
>    currently runs on Macintoshes w/ A/UX, DECstations, VAXstations, Sun
>    3/xx's, Sun SPARCstations, RISC/6000s, and PS/2s w/ AIX. The only way
>    to maintain this application is to use the same source files for all
>    of these different platforms, and to NFS-mount the source directory
>    wherever it is needed. Currently, the source resides on a DECstation
>    hard disk. Below the source directory is a subdirectory for each
>    platform; compiler output (i.e. `.o' files) and the linked application
>    go into the appropriate subdirectory. This strategy works admirably
>    for every machine but (you guessed it) the Macintosh. In order to get
>    the Macintosh version to work, I must compile and link on a non-NFS
>    disk. (Actually, I've never tried compiling on NFS disks and then
>    linking on local disk, too much work.)
>
>My conclusion is that A/UX 2.0's NFS is in some way incompatible with NFS on
>the DECstation, but I don't know enough about NFS to be more precise. I've
>had several people offer impromptu explanations/rationalizations, but
>nothing I felt was truly definitive.

I would like to personally know if this only happens with the object files
residing on the DECStation. Is it OK with the Sparcstation used as 
the source server? Nota Bene the NFS code is pure Sun NFS code, so the
implementation should be the same as the Sun specs.

Most of the problems I've seen with NFS are Yellow Pages configuration
problems concerning access. If in this case you have access to the binaries/
object code, and something does not work, is there maybe some dependencies
of files that have to be accessed from other filesystems? As you see
it's quite hard to define the problem without having a little bit more
evidence and configuration information.

Well, back to work.
Kent

-- 
Kent Sandvik, Apple Computer Inc, Developer Technical Support
NET:ksand at apple.com, AppleLink: KSAND  DISCLAIMER: Private mumbo-jumbo
Zippy++ says: "C++ was given to mankind, so that we might learn patience"