[Libreoffice] gbuildized xml2cmp breaks Windows (was: Tinderbox failure, last success: 2011-09-13 20:44:55)

2011-09-15 Thread Stephan Bergmann
On 09/15/2011 09:11 AM, Stephan Bergmann wrote: http://cgit.freedesktop.org/libreoffice/core/commit/?id=e728feaeebae96df5566bdb6d5f0458983d843ad On Windows, xml2cmp depends on uwinapi from sal. should probably fix the below problem. Turns out that that fix (making xml2cmp depend on sal)

Re: [Libreoffice] gbuildized xml2cmp breaks Windows (was: Tinderbox failure, last success: 2011-09-13 20:44:55)

2011-09-15 Thread Fridrich Strba
Boy, this uwinapi is something that should die quickly. We even almost had it dead but it happens that the Duden orthograph corrector is linking with it. Just have some windows specific code branches for the string functions that actually remain in places where it actually matters would be the

Re: [Libreoffice] gbuildized xml2cmp breaks Windows (was: Tinderbox failure, last success: 2011-09-13 20:44:55)

2011-09-15 Thread Tor Lillqvist
OK, clearly the time now has come to get rid of uwinapi completely. Our uwinapi.dll only contains four functions nowadays: snprintf, snwprintf, vsnprintf and vsnwprintf. We should move those to sal or something. And for those pesky binary extensions that might want an ABI stable uwinapi.dll, let's

Re: [Libreoffice] gbuildized xml2cmp breaks Windows

2011-09-15 Thread Michael Stahl
On 15.09.2011 11:13, Tor Lillqvist wrote: OK, clearly the time now has come to get rid of uwinapi completely. Our uwinapi.dll only contains four functions nowadays: snprintf, snwprintf, vsnprintf and vsnwprintf. We should move those to sal or something. And for those pesky binary extensions

Re: [Libreoffice] gbuildized xml2cmp breaks Windows

2011-09-15 Thread Stephan Bergmann
On 09/15/2011 11:37 AM, Michael Stahl wrote: i think somebody once told me that the last remaining functions are only required on Windows 2000, and if we raised the baseline to Windows XP then it would be unnecessary. any idea if that is true? No, looks like snprintf etc. from uwinapi are

Re: [Libreoffice] gbuildized xml2cmp breaks Windows

2011-09-15 Thread Stephan Bergmann
On 09/15/2011 11:13 AM, Tor Lillqvist wrote: OK, clearly the time now has come to get rid of uwinapi completely. Our uwinapi.dll only contains four functions nowadays: snprintf, snwprintf, vsnprintf and vsnwprintf. We should move those to sal or something. And for those pesky binary extensions

Re: [Libreoffice] gbuildized xml2cmp breaks Windows

2011-09-15 Thread Tor Lillqvist
Patches welcome. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] gbuildized xml2cmp breaks Windows

2011-09-15 Thread Stephan Bergmann
On 09/15/2011 12:36 PM, Tor Lillqvist wrote: Patches welcome. Sounds doable (if I find access to a Windows box). -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] gbuildized xml2cmp breaks Windows

2011-09-15 Thread 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

Re: [Libreoffice] gbuildized xml2cmp breaks Windows

2011-09-15 Thread 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

Re: [Libreoffice] gbuildized xml2cmp breaks Windows

2011-09-15 Thread 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