tomc@oakhill.sps.mot.com (Tom Cunningham) (04/03/91)
We are running the 4.3BSD flavor of SR10.3 on a standalone DN4000 (e.g. not on an Apollo ring) which is connected to an Ethernet network of mainly Sun workstations. The Apollo remotely mounts a filesystem on one of the Sun servers using NFS; the line in the Apollo /etc/fstab is as follows: otis:/usr2 /usr2 nfs rw 0 0 0 Otis is the Sun server. I have been compiling and linking C code using the Apollo CPU but reading and writing files from/to the Sun filesystem. This works OK (sometimes the executable execute bits don't seem to get set [?]), but when I compiled with debug (-g) and attempted to load the resulting executable using dbx, I get this: dbx version sr10.3(4) of 7/6/90 17:52 (apollo) reading symbolic information ... dbx: fatal error: type of foo is not a recognized object file type where "foo" is the name of my program. Anyone know what's going on here? If I link to /tmp on the local Apollo disk I get a segmentation fault while dbx is reading the symbolic information! In a related (or maybe unrelated) issue, if I create a symbolic link to an executable file on the Sun server (e.g. both link and file are on the server) the Apollo can't seem to find the file: ./foo: Command not found. If I do an ls -l on ./foo and use the absolute path displayed then the Apollo finds it. Also, if I create an analogous symbolic link in /tmp on the Apollo the file is also found. This leads me to believe there is something wrong with NFS, or the way we have it set up here. I am using the C-shell on the Apollo. -- Tom Cunningham Motorola Inc. Austin TX tomc@bouwsma.sps.mot.com cs.utexas.edu!oakhill!bouwsma!tomc