On Wed, 25 Mar 2009, Barry Fawthrop wrote:
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 guess the code is sloppy that way here and there, yes.
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
This "C++ translation" sounds somewhat abusive. Before furthering your
current course of action, I'd be interested whether there's a way to link
C objects into a C++ program. Anyone knowing more C++ than I?
...because stripping the code apart to make it compile doesn't sound right
to me...
- Felix
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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
