[OpenAFS-devel] Trying to code for Mac OS X

[Felix Frank]

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
>> OpenAFS-devel@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-devel
>
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>