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