Cannot compile external software against OpenAFS headers any more

[Christian Ambach]

Samba has some OpenAFS related features. In order to activate them, Samba needs the OpenAFS headers.
While this has worked with OpenAFS 1.4.x, it stopped working against the current 1.6.x series.

Compilations fail with
/usr/include/afs/afs.h:1418:27: error: field ‘InStatus’ has incomplete type
     struct AFSStoreStatus InStatus;
                           ^
/usr/include/afs/afs.h:1478:16: error: unknown type name ‘afs_ucred_t’
 afs_set_cr_uid(afs_ucred_t *cred, uid_t uid) {
                ^
/usr/include/afs/afs.h:1482:16: error: unknown type name ‘afs_ucred_t’
 afs_set_cr_gid(afs_ucred_t *cred, gid_t gid) {
                ^
/usr/include/afs/afs.h:1487:17: error: unknown type name ‘afs_ucred_t’
 afs_set_cr_ruid(afs_ucred_t *cred, uid_t uid) {
                 ^
/usr/include/afs/afs.h:1491:17: error: unknown type name ‘afs_ucred_t’
 afs_set_cr_rgid(afs_ucred_t *cred, gid_t gid) {

So it looks like there are some types used in the header that are not declared and so the compilation fails.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: libopenafs-dev 1.6.5-1ubuntu3
ProcVersionSignature: Ubuntu 3.11.0-17.31-generic 3.11.10.3
Uname: Linux 3.11.0-17-generic x86_64
NonfreeKernelModules: openafs
ApportVersion: 2.12.5-0ubuntu2.2
Architecture: amd64
Date: Wed May 14 11:13:21 2014
InstallationDate: Installed on 2013-05-07 (371 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release amd64 (20121017.5)
MarkForUpload: True
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: openafs
UpgradeStatus: Upgraded to saucy on 2014-02-26 (76 days ago)

[Anders Kaseorg (andersk)]

It looks like the short story is that afs/afs.h was never really supposed to be a public header, but here we are. See

https://lists.openafs.org/pipermail/openafs-devel/2013-November/019645.html

[Christian Ambach (ambi-h)]

It seems that I can somehow work around it by avoiding the inclusion of afs.h and use other headers like afs_args.h to get to the information that is needed for the build.
But if those files are not considered as part of the OpenAFS API, they might suffer from the same problem in the future, so it would be really good to have a defined set of headers that can be used when building against OpenAFS.

[Russ Allbery (rra-debian)]

Christian Ambach <email address hidden> writes:

> It seems that I can somehow work around it by avoiding the inclusion of
> afs.h and use other headers like afs_args.h to get to the information
> that is needed for the build.

> But if those files are not considered as part of the OpenAFS API, they
> might suffer from the same problem in the future, so it would be really
> good to have a defined set of headers that can be used when building
> against OpenAFS.

It would be very good to have that. Unfortunately, such a thing doesn't
really exist. There's never been a stable OpenAFS API, and the last that
I heard upstream was still uncomfortable with declaring a stable API.

The ABI is relatively stable, once you can get things to link, at least
for libafsauthent and libafsrpc. But the headers change from time to time
in ways that aren't very backward-compatible. (libkopenafs is an
exception; I wrote it from the start to have a very stable API and ABI.
But that's not the functionality you're looking for, I suspect.)

--
Russ Allbery (<email address hidden>) <http://www.eyrie.org/~eagle/>