[OpenAFS-devel] Mac OS 10.9 compile error

[Benjamin Kaduk]

On Fri, 10 Jan 2014, Benjamin Kaduk wrote:

> On Wed, 25 Dec 2013, Jason Edgecombe wrote:
>
>> Hi everyone,
>> 
>> Thanks to Dave Botsch for setting up a new Mac OS 10.9 build slave. Dave 
>> requests that this build slave be added as a gerrit-triggered builder, but 
>> there are some compile problems blocking that. Please look into this. 
>> Thanks.
>
> Since my new laptop is running Mavericks, I took a look at what the issues 
> were.  The tree at https://github.com/kaduk/openafs/commits/osx should build 
> in the buildbot configuration, but most of the commits are just placeholders 
> that band-aid around the issue instead of being a submittable fix.  I'll 
> probably get to clean up at least some of them today.

I did get to clean them up enough to be submitted to gerrit.  Not all of 
them are clear-cut, and if we do end up adding a library routine as in the 
current version, it will need to be added to the Windows build system, 
etc..

I'm somewhat concerned that we now get a lot of warnings in the build log 
for the kernel module, things like:
In file included from 
/Users/buildbot/slave1/macos-10-9-x86_64-builder/build/src/afs/afs_analyze.c:34:
In file included from 
/Users/buildbot/slave1/macos-10-9-x86_64-builder/build/src/afs/afsincludes.h:49:
/Users/buildbot/slave1/macos-10-9-x86_64-builder/build/src/afs/afs_chunkops.h:91:5: 
warning: implicit declaration of function 'memcpy' is invalid in C99 
[-Wimplicit-function-declaration]
     memcpy(dst, src, sizeof(afs_dcache_id_t));
     ^
/Users/buildbot/slave1/macos-10-9-x86_64-builder/build/src/afs/afs_chunkops.h:95:5: 
warning: implicit declaration of function 'memset' is invalid in C99 
[-Wimplicit-function-declaration]
     memset(i, 0, sizeof(afs_dcache_id_t));
     ^

The older builder that's doing triggered builds does not see these 
warnings, and I'm having a hard time figuring out what exactly has 
changed.  There are prototypes in 
/System/Library/Frameworks/Kernel.framework/Headers/string.h, but our 'h' 
link is to '.../Headers/sys' (and our search path would pick up the 
string.h from hcrypto anyway), but I haven't fully convinced myself that 
this is where kernel sources should be getting their memcpy prototypes.

There's also some 'argument unused during compilation' that I guess are 
due to clang posing as gcc and not accepting quite the same arguments.

Thoughts?

-Ben