On 06/30/2011 12:00 PM, Eric Blake wrote:
Gnulib documents that mingw [v]snprintf is broken (it returns -1
on out-of-space, instead of the count of what would have been
printed); but while we were using the snprintf wrapper, we had
not yet been using the vsnprintf wrapper.
* bootstrap.conf (gnulib_modules): Add vsnprintf.
Reported by Matthias Bolte.
---
bootstrap.conf | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
Followup. There are two forks of mingw - the older mingw project is
32-bit only, and has added wrappers into their w32api libraries that
substitute the broken [v]snprintf of msvcrt with a mingw-specific one
that is POSIX-compliant out of the box. Then there is the mingw64
project, which can compile for both 32-bit and 64-bit, and where their
w32api libraries do not yet override [v]snprintf. [For reference,
Fedora 15 uses the older mingw project, but Fedora 16 is hoping to
switch to the newer mingw64 project; meanwhile, cygwin ships with
cross-compilers for both flavors, which is how I tested the vsnprintf
behavior of both flavors]
The gnulib documentation tends to lag various mingw fixes, and (to date)
has not been making any distinction between the mingw and mingw64 projects.
This patch will help mingw64, so it is worth applying. However,
Matthias and I spent some time on IRC and we are quite confused at why
his mingw build is having issues - since mingw uses wrappers that work
and do not need the gnulib replacement in the first place, at least at
configure time, this change to bootstrap.conf did not change anything
for his build. I'm wondering if maybe libtools attempts to directly
invoke ld instead of going through gcc as the linker are causing
problems, where the configure test used gcc and sees the working wrapper
vsnprintf, but then virsh is compiled via libtool and ends up using the
native broken vsnprintf. At least, that's all I was able to guess :(
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org