Hello,
Boy I had no idea --disable-gssapi was so prevalent...
My apologies for breaking it...
On 05/07/2015 07:52 AM, Thorsten Kukuk wrote:
>
> Hi,
>
> On Thu, May 07, Mike Frysinger wrote:
>
>> Starting with commit d5259e751111cb108c784b044296185f543fc0be (Add header
>> definitions for rpc_gss_*() APIs), the gss headers were pulled in all the
>> time leading to build failures like so:
>> CC libtirpc_la-bindresvport.lo
>> In file included from ../tirpc/rpc/svc_auth.h:44:0,
>> from ../tirpc/rpc/rpc.h:68,
>> from bindresvport.c:46:
>> ../tirpc/rpc/rpcsec_gss.h:38:27: fatal error: gssapi/gssapi.h: No such file or directory
>
> Here is my proof of concept how I think we should solve this.
> But there is one part of your patch I have no solution for:
>
>> --- a/tirpc/rpc/svc_auth.h
>> +++ b/tirpc/rpc/svc_auth.h
> [...]
>> @@ -63,8 +67,10 @@ typedef struct SVCAUTH {
>> int (*svc_ah_destroy)(struct SVCAUTH *);
>> } *svc_ah_ops;
>> caddr_t svc_ah_private;
>> +#ifdef HAVE_RPCSEC_GSS
>> svc_rpc_gss_parms_t svc_gss_params;
>> rpc_gss_rawcred_t raw_cred;
>> +#endif
>> } SVCAUTH;
>
> You are changeing the size of a struct here. I'm not sure
> if this will work, if an application is compiled with headers
> where it is disabled and then runs with a tirpc where it is
> enabled. Or the other way around.
> Does somebody have an idea how to solve that?
Maybe some type of place holders?? Since the gssapi
is on by default, they would be knowing breaking it,
if that matters...
>
> Else here is my patch:
Is this patch addition to Mike's patch?
steved.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
