On Thu, May 07, Steve Dickson wrote:
> 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?
No, replacing it except the struct part.
Thorsten
--
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
--
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
