[oe] [meta-networking][PATCH 1/1] yp-tools: fix compile errors
Joe MacDonald
Joe_MacDonald at mentor.com
Thu Aug 18 18:20:03 UTC 2016
[Re: [oe] [meta-networking][PATCH 1/1] yp-tools: fix compile errors] On 16.08.18 (Thu 16:52) Slater, Joseph wrote:
>
>
> > -----Original Message-----
> > From: openembedded-devel-bounces at lists.openembedded.org [mailto:openembedded-devel-
> > bounces at lists.openembedded.org] On Behalf Of Khem Raj
> > Sent: Wednesday, August 17, 2016 4:20 PM
> > To: openembedded-devel at lists.openembedded.org
> > Subject: Re: [oe] [meta-networking][PATCH 1/1] yp-tools: fix compile errors
> >
> >
> > > On Aug 17, 2016, at 1:22 PM, Joe Slater <jslater at windriver.com> wrote:
> > >
> > > Fix two fatal warnings. The cast error only
> > > occurs for some architectures.
> > >
> > > Signed-off-by: Joe Slater <jslater at windriver.com>
> > > ---
> > > .../nis/yp-tools/alignment-cheat.patch | 58 ++++++++++++++++++++
> > > .../recipes-support/nis/yp-tools_3.3.bb | 3 +-
> > > 2 files changed, 59 insertions(+), 2 deletions(-)
> > > create mode 100644 meta-networking/recipes-support/nis/yp-tools/alignment-cheat.patch
> > >
> > > diff --git a/meta-networking/recipes-support/nis/yp-tools/alignment-cheat.patch b/meta-
> > networking/recipes-support/nis/yp-tools/alignment-cheat.patch
> > > new file mode 100644
> > > index 0000000..856e42e
> > > --- /dev/null
> > > +++ b/meta-networking/recipes-support/nis/yp-tools/alignment-cheat.patch
> > > @@ -0,0 +1,58 @@
> > > +yp-tools: avoid fatal cast warning
> > > +
> > > +The way casting is done, we will get a fatal alignment warning on some
> > > +architectures. This patch cheats our way around this.
> > > +
> >
> > These changes look fine, however you should run it by the upstream.
>
> Version 4.2 of the tools seems to bear little resemblance to 3.3. The code and
> structures patched here no longer exist.
Hmm, in that case, I wonder why we wouldn't just do the uprev to 3.5
(the end of the line for the 3.x series) or 4.2. More thinking out loud
than anything, I suppose, but if you know of a good reason to not push
3.3 off a cliff entirely, let me know.
> > > +We also eliminate an unused constant which causes a fatal warning.
> > > +
> > > +Upstream-status: Pending
> > > +
> > > +Signed-off-by: Joe Slater <jslater at windriver.com>
> > > +
> > > +
> > > +--- a/lib/do_ypcall.c
> > > ++++ b/lib/do_ypcall.c
> > > +@@ -44,7 +44,9 @@ struct dom_binding
> > > + typedef struct dom_binding dom_binding;
> > > +
> > > + static const struct timeval RPCTIMEOUT = {25, 0};
> > > ++#if 0
> > > + static const struct timeval UDPTIMEOUT = {5, 0};
> > > ++#endif
> >
> > perhaps its better to remove the unused code instead of making preprocessor
> > work even more.
>
> Probably. I think RPCTIMEOUT made it to 4.2, but UDPTIMEOUT did not.
So please make this change in your v2, then. It's a personal bias
thing, probably, but it seems to me there's almost never any value to
leaving a "#if 0" block in code these days. Particularly not when
we're talking about a patch that gets applied by quilt in the build
system which is then trivial to restore the deleted code if, for some
reason, you need it.
-J.
> > > + static int const MAXTRIES = 2;
> > > + static pthread_mutex_t ypbindlist_lock = PTHREAD_MUTEX_INITIALIZER;
> > > + static dom_binding *ypbindlist = NULL;
> > > +@@ -381,7 +383,7 @@ __ypclnt_call (u_long prog, xdrproc_t xa
> > > +
> > > + int
> > > + do_ypcall (const char *domain, u_long prog, xdrproc_t xargs,
> > > +- caddr_t req, xdrproc_t xres, caddr_t resp)
> > > ++ caddr_t req, xdrproc_t xres, void *resp)
> > > + {
> > > + dom_binding *ydb;
> > > + int status;
> > > +@@ -450,9 +452,9 @@ do_ypcall (const char *domain, u_long pr
> > > + /* Like do_ypcall, but translate the status value if necessary. */
> > > + int
> > > + do_ypcall_tr (const char *domain, u_long prog, xdrproc_t xargs,
> > > +- caddr_t req, xdrproc_t xres, caddr_t resp)
> > > ++ caddr_t req, xdrproc_t xres, void *resp)
> > > + {
> > > +- int status = do_ypcall (domain, prog, xargs, req, xres, resp);
> > > ++ int status = do_ypcall (domain, prog, xargs, req, xres, (void *) resp);
> >
> > resp is already a void pointer why is this typecast needed ?
>
> I put it in someplace along the line in trying to fix the problem and forgot
> to take it out.
>
> V2 or leave it? This code does not look like it's going anywhere beyond here.
>
> Joe
>
>
> >
> > > + if (status == YPERR_SUCCESS)
> > > + /* We cast to ypresp_val although the pointer could also be of
> > > + type ypresp_key_val or ypresp_master or ypresp_order or
> > > +--- a/lib/internal.h
> > > ++++ b/lib/internal.h
> > > +@@ -17,8 +17,8 @@
> > > + #define _INTERNAL_H_
> > > +
> > > + extern int do_ypcall (const char *domain, u_long prog, xdrproc_t xargs,
> > > +- caddr_t req, xdrproc_t xres, caddr_t resp);
> > > ++ caddr_t req, xdrproc_t xres, void *resp);
> > > + extern int do_ypcall_tr (const char *domain, u_long prog, xdrproc_t xargs,
> > > +- caddr_t req, xdrproc_t xres, caddr_t resp);
> > > ++ caddr_t req, xdrproc_t xres, void *resp);
> > > + extern int yp_maplist (const char *, struct ypmaplist **);
> > > + #endif
> > > diff --git a/meta-networking/recipes-support/nis/yp-tools_3.3.bb b/meta-
> > networking/recipes-support/nis/yp-tools_3.3.bb
> > > index b89f0b8..69217fa 100644
> > > --- a/meta-networking/recipes-support/nis/yp-tools_3.3.bb
> > > +++ b/meta-networking/recipes-support/nis/yp-tools_3.3.bb
> > > @@ -11,11 +11,10 @@ ypwhich, yppasswd, domainname, nisdomainname \
> > > and ypdomainname. \
> > > "
> > >
> > > -PNBLACKLIST[yp-tools] ?= "BROKEN: fails to build for qemuarm."
> > > -
> > > SRC_URI = "http://www.linux-nis.org/download/yp-tools/${BP}.tar.bz2 \
> > > file://domainname.service \
> > > file://yp-tools-ipv4-ipv6-Provide-an-in-place-version-of-mapv4v6addr.patch \
> > > + file://alignment-cheat.patch \
> > > "
> > > SRC_URI[md5sum] = "acebeecc11a73fb8097503670344834c"
> > > SRC_URI[sha256sum] = "812be817df3d4c25813552be336c6c6ad5aedaf65611b81af3ad9f98fb3c2e50"
> > > --
> > > 1.7.9.5
> > >
> > > --
> > > _______________________________________________
> > > Openembedded-devel mailing list
> > > Openembedded-devel at lists.openembedded.org
> > > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>
--
-Joe MacDonald.
:wq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-devel/attachments/20160818/48d0ba52/attachment-0002.sig>
More information about the Openembedded-devel
mailing list