[Libreoffice] gbuildized xml2cmp breaks Windows (was: Tinderbox failure, last success: 2011-09-13 20:44:55)
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) introduced a circular dependency (as sal already depends on xml2cmp). The problem is that before gbuildization, xml2cmp was careful not to link against uwinapi (via UWINAPILIB=$(0) in xml2cmp/util/makefile.mk); this needs to be re-implemented in gbuild. -Stephan On 09/15/2011 08:47 AM, ke...@suse.cz wrote: Hi folks, One of you broke the build of LibreOffice with your commit :-( Please commit and push a fix ASAP! Full log available at http://tinderbox.libreoffice.org/MASTER/status.html Tinderbox info: Box name: Windows XP SP3 Machine: CYGWIN_NT-5.1 steve 1.7.9(0.237/5/3) 2011-03-29 10:10 i686 Cygwin Configured with: --disable-directx --disable-mozilla --without-junit --disable-binfilter --with-ant-home=/home/kendy/apache-ant-1.8.1 Commits since the last success: core 45589f1 gbuildize automation 6c8a7e0 pass -s flag to custom target's make process a3c3d70 be silent c79e42d be silent c40f634 work silently for make -s 37356b7 allow to specify additional deps for zip target 0510c98 WaE: declaration of 'index' shadows a global declaration b2d9db4 WaE: declaration of 'i' shadows a previous local 30bf29f WaE: declaration of 'j' shadows a previous local 7a7f10e forgot another csv file 4fe0797 add formats test for xls and xlsx 2b75f59 improve calc's format unit test 032fca6 deliver libcrmf.a 0c113d8 Fix of localised template name problems in Impress part 1 b6cccb9 Fix nSearchType vs. nMatchType typo and simplify resulting code. fb1e454 Don't always set refresh flag on export. This is a bad hack. 2f65414 Check the source range when refreshing, and abort refresh if invalid. 932ee04 Introduced CHECK_PARALLELISM (and poshed the code up). a75cb23 default shortcut for .uno:SearchDialog should be Ctrl+H 27dcdb1 New unit test case for testing SHEETS function result. dd482fd do not try to read from an iterator which we just deleted from the container e26ea36 Revert Revert i#118224: kill O(n^2) complexity of unique bookmark name creation 9015c60 Do the same when calling ScDocument::InsertTabs(). 892f8b5 fdo#35965: Mark all formula cells dirty when appending a new sheet. b7998b6 No need to bark about G_SLICE on stderr. 188696a don't crash b7912ec don't quote ???x??? 0a97ece merge srvdepy functions into xml2cmp and simplify xml2cmp gbuild 8578e3c Related: fdo#40599 add a initial basic test for deleting graphics c046147 Folded smoketestdoc back into smoketestoo_native; no need to have it separated. 05a6605 Revert i#118224: kill O(n^2) complexity of unique bookmark name creation 387620b Removed solenv/bin/subsequenttests, moved its (improved) content directly into Makefile.in. 109ca35 Added more missing dependencies on solenv back into build.lsts. 333648c added twofold affix+compound to hunspell, as the official fixed https://sourceforge.net/tracker/index.php?func=detailaid=3288562group_id=143754atid=756395 6caaa5e default to -r on gbuild for performance (assumed esp. on make 3.82) 79dc19f ByteString-rtl::OStringBuffer 98ae11b pointless foo 33aa323 callcatcher: remove unused code 4a3db11 ImplUpdateStringFromUniString is now dangling 1cd1e4a use read_uInt8s_AsOString here 84db141 forgot the csv file for number formats 61732a8 add unit test for formated cells b6d3f5c ScCompiler::IsDBRange compares upper case strings ba361f9 add database unit test 32ca2cb Updated csv_parser from orcus. 689bde9 Some cppcheck cleaning dictionaries help The error is: build failed - error is:: log for /cygdrive/c/libo/xml2cmp/prj cd .. make -s -r -j1 make -s -r deliverlog [ info ALL ] LinkTarget Library/uwinapi.lib not defined: Assuming headers to be there! [ info ALL ] LinkTarget Library/advapi32.lib not defined: Assuming headers to be there! [ build CXX ] xml2cmp/source/xcd/main [ build CXX ] xml2cmp/source/support/cmdline [ build CXX ] xml2cmp/source/support/heap [ build CXX ] xml2cmp/source/support/sistr [ build CXX ] xml2cmp/source/support/syshelp [ build CXX ] xml2cmp/source/support/badcast [ build CXX ] xml2cmp/source/xcd/cr_html [ build CXX ] xml2cmp/source/xcd/cr_index -- [ build CXX ] xml2cmp/source/xcd/cr_metho [ build CXX ] xml2cmp/source/xcd/filebuff [ build CXX ] xml2cmp/source/xcd/parse [ build CXX ] xml2cmp/source/xcd/xmlelem [ build CXX ] xml2cmp/source/xcd/xmltree [ build CXX ] xml2cmp/source/xcd/dependy [ build DEP ] LNK:Executable/xml2cmp.exe [ build DEP ] LNK:Executable/xml2cmp.exe [ build DEP ] LNK:Executable/xml2cmp.exe [ build LNK ] Executable/xml2cmp.exe Microsoft (R) Incremental Linker Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. c:/libo/workdir/wntmsci12.pro/CxxObject/xml2cmp/source/xcd/main.o
Re: [Libreoffice] gbuildized xml2cmp breaks Windows (was: Tinderbox failure, last success: 2011-09-13 20:44:55)
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 solution. And a healthy pressure on the Duden folks so that they recompile the stuff against our SDK would solve the only situation where this library is still needed. On Thu, 2011-09-15 at 09:22 +0200, Stephan Bergmann wrote: Turns out that that fix (making xml2cmp depend on sal) introduced a circular dependency (as sal already depends on xml2cmp). The problem is that before gbuildization, xml2cmp was careful not to link against uwinapi (via UWINAPILIB=$(0) in xml2cmp/util/makefile.mk); this needs to be re-implemented in gbuild. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows (was: Tinderbox failure, last success: 2011-09-13 20:44:55)
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 just keep around one from 3.3 or 3.2 times and include it in the installer. Fridrich shares my thoughts about this. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
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 that might want an ABI stable uwinapi.dll, let's just keep around one from 3.3 or 3.2 times and include it in the installer. Fridrich shares my thoughts about this. --tml but moving the functions to sal will not help at all with the circular dependency problem, it will just create a new problem with backward compatibility. why are the remaining functions still there? AFAIK uwinapi is a library that contains functions that are available in win32 but where the implementation is buggy on some version of Windows(R); the intent was to ship a corrected version so client code doesn't have to work around the bugs. 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? -- Theorem: All positive integers are interesting. Proof: Assume the contrary. Then there is a lowest non-interesting positive integer. But, hey, that's pretty interesting! A contradiction. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
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 still needed on recent Windows, as Windows' _snprintf etc. are not standards conformant (see http://stackoverflow.com/questions/1270387/are-snprintf-and-friends-safe-to-use), and there still appear to be no standards conformant true snprintf etc. in the Windows API. -Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
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 that might want an
ABI stable uwinapi.dll, let's just keep around one from 3.3 or 3.2
times and include it in the installer.
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.
(A drawback of moving those functions to sal is that it could easily
lead us into a similar situation in the future as we have today. If,
for example, Windows one day will make conforming versions of those
functions available and we would like to remove them from our code base,
external code more-or-less accidentally binding against the versions
from sal might give us a hard time removing them again.)
-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
Patches welcome. --tml ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
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
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
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
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
Fridrich
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] gbuildized xml2cmp breaks Windows
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
