paquette@cpsc.ucalgary.ca (Trevor Paquette) (02/22/89)
Ok I give up.. what is the secret to getting the rpc include
files to work on a Persona Iris? Don't people test these things
before they are shipped???
(NOTE: this is after I have done
'ln -s /usr/include/bsd/netinet /usr/include/netinet' to get
a netinet dir for rpc.h to use.. is wrong as well..
Scenario: try this through 'cc -o t t.c'
#include <rpc/rpc.h> \
main() | this is t.c
{ |
} /
Dies with the following error:
ccom: Error: /usr/include/rpc/svc.h, line 209: syntax error
extern fd_set svc_fds;
--------------------^
A SYNTAX ERROR??? in an INCLUDE FILE????? what gives? What is 'fd_set'???
taking a closer look at the include file this is what those lines
look like..
/*
* Lowest level dispatching -OR- who owns this process anyway.
* Somebody has to wait for incoming requests and then call the correct
* service routine. The routine svc_run does infinite waiting; i.e.,
* svc_run never returns.
* Since another (co-existant) package may wish to selectively wait for
* incoming calls or other events outside of the rpc architecture, the
* routine svc_getreq is provided. It must be passed readfds, the
* "in-place" results of a select system call (see select, section 2).
*/
#ifndef KERNEL
/* dynamic; must be inspected before each call to select */
#ifdef sgi
209>extern fd_set svc_fds;
#else
extern int svc_fds;
#endif
So I try 'cc -o t -Usgi t.c' seems to to futher this time.. In fact
it compiles just fine..
So why are there errors in the include files??
==============================================================================
Trevor Paquette/GraphicsLand, Calgary, Alberta
..uunet!{ubc-cs,utai,alberta}!calgary!paquette ICBM:51 03 N/114 05 W
calgary!paquette@cs.ubc.ca Luminous beings we are, not this crude mattervjs@rhyolite.SGI.COM (Vernon Schryver) (02/23/89)
In article <769@cs-spool.calgary.UUCP>, paquette@cpsc.ucalgary.ca (Trevor Paquette) writes: > Ok I give up.. what is the secret to getting the rpc include > files to work on a Persona Iris? The secret is to use "-I/usr/include/bsd" if you want to compile "BSD" style code, and "-I/usr/include/sun" for code related to a company with solar connotations. This is documented in the manuals, although since many people miss it, not clearly enough. Since we ship "SV with 4.3BSD enhancements," one generally has to fiddle with at least the makefiles when porting BSD code. Remember that SGI has (since V-kernel days) shiped AT&T-style, SV UNIX. There are symantic as well as silly syntactic conflicts between SV and 4.xBSD. For that reason, we chose to put the BSD and Sun include files in their own directories. Similarly, there are /usr/lib/libbsd.a and /usr/lib/libsun.a libraries. Over time, many things from libbsd.a and /usr/include/bsd have crept into /usr/include and libc.a. However, there is only so far that we can go without breaking SVID--at least until the millenium arrives with SVR4. One of the most egregious conflicts is with what you want when you use 'seekdir(3)' and friends. > A SYNTAX ERROR??? in an INCLUDE FILE????? what gives? What is 'fd_set'??? > taking a closer look at the include file this is what those lines > look like.. If you use "-I/usr/include/bsd", then when you "#include <sys/types.h>", you will get the 4.3BSD select(2) definitions. > #ifndef KERNEL > /* dynamic; must be inspected before each call to select */ > #ifdef sgi > 209>extern fd_set svc_fds; > #else > extern int svc_fds; ^^^ > #endif The "int" is the bug--at least with 4.3BSD. To make it easier to track the ever changing NFS code (which changes just like ours and everyone else's), we use lots of ifdef's. In 4.3BSD, using an 'int' for select(2) is a No-No. Imagine if you happen to get file descriptor 33, not to mention 99. The use of int's for select(2) was a botch in 4.2BSD which was fixed in 4.3BSD. Remember that SunOS 3.* was based on 4.2 BSD, while SGI uses 4.3BSD. > > So I try 'cc -o t -Usgi t.c' seems to to futher this time.. In fact > it compiles just fine.. Yes, but it may not work. Vernon Schryver Silicon Graphics vjs@sgi.com