On 10/28/2013 12:05 PM, Doug Goldstein wrote: > With Mac OS X 10.9, xdrproc_t is no longer defined as: > > typedef bool_t (*xdrproc_t) (XDR *, void *, ...); > > but instead as > > typedef bool-t (*xdrproc_t) (XDR *, void *, unsigned int); > > The rationale explained in the header is that using a vararg is > incorrect and has a potential to change the ABI slightly. They decided > to specify the exact number of parameters and for compatibility with old > code decided to make the signature require 3 arguments. The third > argument is ignored for cases that its not used and its recommended to > supply a 0. > --- > configure.ac | 41 +++++++++++++++++++++++++++++++++++++++++ > src/rpc/virnetmessage.c | 10 ++++++++-- > 2 files changed, 49 insertions(+), 2 deletions(-) > I'd like some feedback from someone else who can actually test this on MacOS, as well as FreeBSD, but it does seem reasonable to get in 1.1.4. > diff --git a/configure.ac b/configure.ac > index 1c5b168..f2bae88 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -697,6 +697,47 @@ if test x"$with_remote" = x"yes" || test x"$with_libvirtd" = x"yes"; then > *) XDR_CFLAGS=$lv_cv_xdr_cflags ;; > esac > AC_SUBST([XDR_CFLAGS]) Not your fault, but we probably ought to move xdr stuff into m4/virt-xdr.m4 - but that can wait till post-release. > + AC_DEFINE_UNQUOTED([XDRPROC_T_ARG_COUNT], [$lv_cv_xdrproc_t_args], > + [number of arguments that xdrproc_t func ptr takes]) Seems reasonable; but I'm a bit worried about accepting args=2 in the cases where we actually needed the varargs to pass 3. It may be safer to pass 3 always, unless we have empirical evidence that uclibc will fail to compile if we don't limit to exactly 2 (and not just a thread archives where they were contemplating forcing just 2, but where I don't know if the thread was actually applied as a patch). > > +#if XDRPROC_T_ARG_COUNT == 3 > +# define VIR_XDRPROC(proc, xdr, data) ((proc)((xdr), (data), 0)) > +#else > +# define VIR_XDRPROC(proc, xdr, data) ((proc)((xdr), (data))) > +#endif This seems like a nice abstraction for the problem at hand. Here's hoping we get someone to provide test results in a timely manner. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list