Thanks Frank I'm using the XCode compiler and compiling everything as an Objective-C++ project converting all .c -> .mm Yes it is very strict for example when I was building the kerberos functions they would have
char *name name = malloc(sizeof(name)); This would throw and error about void * and char * I had to change to the following name = (char *)malloc(sizeof(name)); I'm still not sure how to deal with the xdr_ops as it is apart of the XDR struct and yet the functions inside need XDR as the first parameter so right now they are declared as void * Thanks all Felix Frank wrote: > On Tue, 24 Mar 2009, Barry Fawthrop wrote: > >> Greetings, >> I'm trying to code an openafs based application in Xcode for the Mac OS X >> >> >> I have copied much of the needed course code from 1.5.57 tarball >> in ubikclient.mm it has the ubik_Call >> Which has the >> code = VOTE_GetSyncSite line >> >> I can't find this anywhere >> >> If I search the Internet I find references to an ubik_int.c file >> which has this >> If I create this file then it has further issues The biggest being > > Functions like that are generated using rxgen. Look at ubik/ubik_int.xg. > It says "prefix S" (as is common). > To find the implementation for the above call, prepend the S. > The function you need is SVOTE_GetSyncSite(). The call above is to the > stub routine (which is generated). > "Copying needed source from the tarball" has such pitfalls. I think you > need to get the necessary .xg files and add the appropriate rules to > your Makefile (or run rxgen by hand if that's how you play it). > >> in xdr_mem.c the line >> >> static struct xdr_ops xdrmem_ops = >> ERROR: variable 'xdr_ops xdrmem_ops' has initializer but incomplete >> type >> xdrmem_getint32, >> xdrmem_putint32, >> .... >> .... >> >> }; > > Hmm, I haven't come around to fiddling with 1.5.x sources (are you sure > that is what you want, by the way? For *NIX environments, that's the > unstable branch after all.) > > ...BUT I did have issues with xdrmem while adding some code to OpenAFS+OSD, > not at compiletime however. Turned out the xdrmem package has never been > linked into 1.4.x. > Still, the code compiled fine, linking to xdrmem routines from GLIBC > (which in turn led to gross misbehaviour, but that's a different story). > > The error is weird. Barring any changes between 1.5.56 and 57 it builds > in i586_rhel50. Maybe your compiler doesn't like how struct xdr_ops is > declared inside struct XDR. > > What's your compiler? Are you sure you're using the same options as > during a "make" in an openafs build tree? > > Regards > Felix > _______________________________________________ > OpenAFS-devel mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-devel _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
