Red Hat Bugzilla – Bug 50422
rpm 4.0.3 CVS: Use of __va_copy().
Last modified: 2008-03-13 15:18:51 EDT
Fresh CVS of rpm 4.0.3/rpmio/rpmlog.c uses __va_copy() in the event that GLIBC is not defined and/or not recent enough. This works fine for most platforms if you're using gcc, since it implements that (former) extension. Most vendor compilers, including the up-to-date Forte C compiler on Solaris don't have that (it does have va_copy() in stdarg.h, though). Note that va_copy() is part of the C9X standard now, but it will likely be a while before it's been implemented in most compilers. I'm not sure why the call to __va_copy() is there -- the code is the same for the GLIBC case where 2 < glibc version < 2.1.x *except* that the __va_copy() is missing there. In any case, depending on __va_copy() is going to provide for portability problems.
__va_copy was added, and is apparently necessary, on ppc-linux and s390-linux. There was a recent note on rpm-list (from Franz Sirl?) asking for yet another fiddle with __va_copy.
Thanks, I'll check through the archive. Since it's needed on some architectures, the best thing might be to check for its existence with configure. The question is, are there platforms where it does any harm?
__va_copy is in stdarg.h and/or varargs.h, so you should look in the gcc-lib private include. Meanwhile, since I have no platform that *must* have __va_copy, I'm gonna defer this bug until someone tells me the right thing to do.