Re: [libvirt] [PATCH] build: fix virBufferVasprintf on mingw

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 :(