[Libreoffice] gbuildized xml2cmp breaks Windows

[Fridrich Strba]

Stefan,

On Thu, 2011-09-15 at 12:10 +0200, Stephan Bergmann wrote: 
> But instead of moving those functions to, say, sal, why not keep them in 
> a library called uwinapi.dll?  And do the clean-up of not including that 
> library implicitly in every linker call on Windows (i.e., remove it from 
> gb_STDLIBS and old STD{LIB,SHL}{GUI,CUI}MT), but explicitly in only 
> those that actually use it.

I would even contend to detect the code that uses those functions and
see whether they cannot be fixed in the code itself. The problem now is
that if there are extensions out there that are linking with uwinapi.dll
(and there is actually one that we know about), they are for sure not
linking with the uwinapi.dll that comes with LO 3.4.x, but with
something from 3.3.x. The ABI of this library changed (maybe by mistake)
between 3.3.x and 3.4.x release cycles.

My suggestion would be -- for windows builds -- not to link with
uwinapi.dll at all and detect the use of the snprintf functions and
check whether they actually need to be compliant in that particular use
and if yes, do some magic around them. For instance, in libwpd I do
this:
http://libwpd.git.sourceforge.net/git/gitweb.cgi?p=libwpd/libwpd;a=blob;f=src/lib/WPXString.cpp;h=b9da3124fe47641ec446cadb284379215d7aaa8a;hb=HEAD#l136

This would have the merit of not linking with uwinapi.dll anymore and
not to distribute any headers/import libraries for it in our SDK, so
that extension-writers can little-by-little move out of it.

Just my 2 cts and given the exchange rate, not much

F.