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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
