(Illustration by Gaich Muramatsu)
On Mon, Aug 06, 2007 at 07:38:58AM -0400, Greg Troxel wrote: > I'm in the process of updating pkgsrc for the new releases, and updated > rpc2 first: > > lwp-2.3 Light Weight Process style threads > rpc2-2.6 CMU (Coda) remote procedure call package > rvm-1.14 Recoverable Virtual Memory > > Then I tried to build the coda 6.9.1 package (I had increased it's > PKGREVISION because of the rpc2 shlib major bump and wanted to test). > It fails, and it looks like there was an API change as well with > renaming CFOO to FOO. I'll just updated to 6.9.2. > > c++ -fno-exceptions -fcheck-new -Wall -MD -DHAVE_CONFIG_H -D__BSD44__ -I. -I/n0/gdt/NetBSD-current/pkgsrc/net/coda/work/coda-6.9.1/include -I/n0/gdt/NetBSD-current/pkgsrc/net/coda/work/coda-6.9.1 -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include -I/usr/include -c -o updatesrv.o updatesrv.cc > updatesrv.cc: In function 'long int UpdateFetch(RPC2_Handle, RPC2_Byte*, RPC2_Unsigned, RPC2_Unsigned*, RPC2_Unsigned*, RPC2_Integer*, SE_Descriptor*)': > updatesrv.cc:475: error: 'CEACCES' was not declared in this scope Yeah, that was an error define that updatesrv.cc should never have used to begin with. It really wanted to return EACCESS which in the rpc2 library would get 'translated' to a platform independent CEACCESS (=13). If updatesrv is returning CEACCESS, rpc2 would interpret this as whatever errno happens to be mapped to value 13 and translate this to some totally different platform independent error. So that was really a bug, the only reason it 'worked' (at least on Linux) was because EACCESS is also defined as error 13, so CEACCESS happens to get interpreted as if the application returned EACCESS. And yes there was an API change, RPC2-2.6 keeps the internal platform independent values internal. For instance, some OS may not defined EMLINK themselves, so we define it as 500 + rpc2 value for EMLINK. For instance, the on-the-wire value for VNOSERVICE is 105, and the value that venus sees will be 605. Previously we would use 105 both on the wire and in venus which was confusing when we returned VNOSERVICE back to rpc2 as it happens to be same value as ENOBUFS on Linux, and now we don't really know anymore which error this is supposed to be. JanReceived on 2007-08-06 23:12:15