Andrew Dunstan wrote:
> Tom Lane wrote:
>
>> "Andrew Dunstan" <andrew@dunslane.net> writes:
>>
>>> I have just discovered a tiny fix that is needed when compiling on
>>> Windows
>>> with a very late model libintl.h. Essentially we need to add vfprintf to
>>> the list of items we stop the libintl headers from hijacking. I am still
>>> testing, but this change (3 extra lines in port.h) should be very low
>>> risk.
>>>
>> Hm, you mean only
>>
>> #ifdef vfprintf
>> #undef vfprintf
>> #endif
>>
>> This seems a bit strange, because the other functions such as vsnprintf
>> have several other relevant bits in port.h, plus supporting code in
>> src/port/ ... why wouldn't we need all of that?
>>
>>
>
>
> *sigh* you could well be right. I will dig some more. It only happens for
> ECPG - everything else links just fine.
>
>
>
Hmm. Well, it turns out that pg_vfprintf is declared static in our
snprintf.c. The only place vfprintf is used in the backend is in elog.c,
although it is used in a variety of frontend programs, so it looks like
this needs to be fixed properly.
Is there any reason we shouldn't treat vfprintf the same as other
members of the printf family? It will certainly mean more that 3 lines,
although I think the changes could possibly still be confined largely to
port.h.
Of course, we could leave this for a dot release - I notice that the
Windows buildfarm members are building happily, and I assume they have
an earlier version of gettext/libiconv than I have just installed on my
new laptop. But that would be a bit of a pity.
cheers
andrew