[Libreoffice] gbuildized xml2cmp breaks Windows

[Stephan Bergmann]

On 09/15/2011 02:57 PM, Fridrich Strba wrote:
> 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.

Do you know in what way it changed?

> 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.

In the SDK, I would not distribute anything for it, anyway.  This should 
really be something private (which is in line with ure/source/README 
flagging it as private).

-Stephan