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.

Jan