Thanks, in advance, for any help. Does anyone know why studio development tools (C, C++, fortran) are only distributed as 32-bit binaries for linux? Studio complains it can't access input files, even though permissions are wide open, when compiling code on an NFS export that supports 64-bit file id's. Unless both the compilers and the code are on the local (UFS) filesystem, or on an NFS export constrained to 32-bit file id's, our builds inevitably break. This is understandable, as 32-bit applications don't understand 64-bit file id's:
bash-3.2$ CC -g -xs -DUNIX -DLINUX -m64 -DWL=64 -Isrc src/my_test.cpp -c -o ./my_test.o Could not open input file "src/my_test.cpp".
bash-3.2$ ls -la src
drwxrwxrwx 2 user1 user1 4096 May 30 09:18 .
drwxrwxr-x 3 user1 user1 4096 Jun 4 10:25 ..
-rwxrwxrwx 1 user1 user1 2048 May 30 07:20 my_test.cpp
-rwxrwxrwx 1 user1 user1 87456 May 30 09:17 a_tester.h
-rwxrwxrwx 1 user1 user1 88823 May 30 09:17 fellow.h
-rwxrwxrwx 1 user1 user1 128 May 30 09:17 ship.h
-rwxrwxrwx 1 user1 user1 3820 May 30 09:17 ship2.h
The question you really need to answer is, "What else is broken?"
Because an open() system call is an open() system call - the kernel doesn't care what application is making it.
Since you mention UFS as being your local file system, that means you're running on Solaris, right? So what kind of server is your NFS server? Linux or Solaris? FWIW, the history of Linux NFS implementations isn't very good, especially in heterogeneous environments.
The local filesystem is actually ext3 on linux, not UFS... my bad. The server is an Isilon storage cluster, which by default returns 64-bit file handles via NFS. Understandably the OS kernel shouldn't care about the app, but when a 64-bit file id is presented back to a 32-bit application such as sunstudio CC, the results lead me to believe it's not supported.
This case is further shown by the fact that when I constrain the NFS share to present 32-bit only file handles, the sunstudio compiler works like a champ.