On Wed, Oct 30, 2013 at 1:30 PM, Doug Goldstein <cardoe@xxxxxxxxxx> wrote: > On Tue, Oct 29, 2013 at 6:28 PM, Eric Blake <eblake@xxxxxxxxxx> wrote: >> 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. > > Gave this a change a whirl on FreeBSD 9.2 and it was fine. But > obviously more testing is better. I tested this patch on FreeBSD 9.2, Mac OS X 0.7.4 and 10.8.5. It worked on all of them. ozaki-r > >>> + 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). > > fwiw, it appears that uclibc master [1] has not gone that route so I'm > not sure what became of that thread. Hard coding our implementation to > always pass 3 arguments was my other approach that I had mentioned on > IRC but I wasn't sure about any negative repercussions on other > platforms. > > [1] http://git.uclibc.org/uClibc/tree/include/rpc/xdr.h#n149 > > -- > Doug Goldstein > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list