On 05/07/2015 11:12 AM, Mike Frysinger wrote:
> On 07 May 2015 13:52, Thorsten Kukuk wrote:
>> 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?
>
> i did notice that, but i would point out that this struct in the 0.2.5 lacked
> these members. they're new to the 0.3.0 release. so if ABI is a concern, we
> already lost that battle ;).
Right.. I knew this was the case...
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
