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

[Eric Blake]

[adding bug-gnulib, bug-gnu-libiconv]

On 07/01/2011 04:50 AM, Matthias Bolte wrote:
> 2011/6/30 Eric Blake <address@hidden>:
>> 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 :(
> 
> Simple tests show that [v]snprintf works correctly with mingw (I
> didn't test mingw64) in case of a too small buffer. It's only broken
> in the context of libvirt. I finally figured out that libintl is the
> cause for this, as Eric already suggested as a possible cause on IRC.
> It's not related to libtool at all.
> 
> libintl.h is included by gnulib's gettext.h, that is included by
> internal.h, that is included by buf.h, that is included by buf.c. This
> it how we get it there to break in libvirt, because libintl.h (from
> http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/gettext-runtime-dev_0.18.1.1-2_win32.zip)
> contains this section
> 
> #if 1
> 
> #if !(defined snprintf && defined _GL_STDIO_H) /* don't override gnulib */
> #undef snprintf
> #define snprintf libintl_snprintf
> extern int snprintf (char *, size_t, const char *, ...);
> #endif
> #if !(defined vsnprintf && defined _GL_STDIO_H) /* don't override gnulib */
> #undef vsnprintf
> #define vsnprintf libintl_vsnprintf
> extern int vsnprintf (char *, size_t, const char *, va_list);
> #endif
> 
> #endif
> 
> gnulib's stdio.h is included prior to the inclusion of libintl.h so
> _GL_STDIO_H is defined, but gnulib detected that it doesn't need to
> replace [v]snprintf, therefore [v]snprintf isn't defined and both
> #if's are true and libintl.h replaces [v]snprintf with it's own broken
> version. I can reproduce the problem in a test program by including
> said libintl.h.
> 

Why is libintl's [v]snprintf broken on mingw?  Even if libintl is
compiled against an older mingw where there is no mingw snprintf
replacement, it seems like libintl should be honoring the correct return
values.

And what can gnulib do to work around the case where mingw has fixed
snprintf, but libintl still has broken snprintf, and thus the gnulib
headers did not define snprintf?  Should the gnulib <stdio.h>
replacement _always_ define snprintf, even if only by:

#define snprintf snprintf

so that inclusion of the gnulib header prior to the libintl headers
forces libintl to leave well enough alone?

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature