A Question about Open Office Password Protected Text Documenets
Dear Sir/Madam I have a large number of important documents that I have created over the years in Open Office, which were created as password protected documents. Is there any likelihood in the future of any ‘redundancy’ or suchlike where these documents would be no longer accessible by future then current software etc? Or will the files always remain safe, in that there will always be an Open Office allied program capable of unlocking their password protected format? I will be very grateful of your reply. With sincere regards Roger Bentley
Re: A Question about Open Office Password Protected Text Documenets
Hi Roger If you saved them in OpenOffice's default format, OpenDocument (.odt / .ods / .odb etc.), then yes. Password protection is part of the OpenDocument standard, and should be supported by us and other OpenDocument software such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The encryption techniques are all well documented and use common well established ciphers, hash functions and password strengthening procedures. With long term storage, the problem won't be data becoming inaccessible due to encryption (provided you remember your passwords), so much as the opposite problem, of data becoming too easily accessible, since older versions of OpenDocument used weaker encryption ciphers, potentially making document encryption too easy to crack by future weaknesses discovered in those ciphers and with more powerful computers in the future. Regards Damjan On Fri, Jun 10, 2016 at 3:42 PM, Roger Bentley wrote: > Dear Sir/Madam > > I have a large number of important documents that I have created over the > years in Open Office, which were created as password protected documents. > > Is there any likelihood in the future of any ‘redundancy’ or suchlike > where these documents would be no longer accessible by future then current > software etc? Or will the files always remain safe, in that there will > always be an Open Office allied program capable of unlocking their password > protected format? > > I will be very grateful of your reply. > > With sincere regards > > Roger Bentley
Re: A Question about Open Office Password Protected Text Documenets
That said, if I had a set of business-critical documents, I would test some sample documents at each major OS, hardware, or office software upgrade. Before decommissioning the last instance of the old system, load and read a few sample documents on the new system. If there is a problem, use the old system to convert to an updated format. On 6/10/2016 7:29 AM, Damjan Jovanovic wrote: Hi Roger If you saved them in OpenOffice's default format, OpenDocument (.odt / .ods / .odb etc.), then yes. Password protection is part of the OpenDocument standard, and should be supported by us and other OpenDocument software such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The encryption techniques are all well documented and use common well established ciphers, hash functions and password strengthening procedures. With long term storage, the problem won't be data becoming inaccessible due to encryption (provided you remember your passwords), so much as the opposite problem, of data becoming too easily accessible, since older versions of OpenDocument used weaker encryption ciphers, potentially making document encryption too easy to crack by future weaknesses discovered in those ciphers and with more powerful computers in the future. Regards Damjan On Fri, Jun 10, 2016 at 3:42 PM, Roger Bentley wrote: Dear Sir/Madam I have a large number of important documents that I have created over the years in Open Office, which were created as password protected documents. Is there any likelihood in the future of any ‘redundancy’ or suchlike where these documents would be no longer accessible by future then current software etc? Or will the files always remain safe, in that there will always be an Open Office allied program capable of unlocking their password protected format? I will be very grateful of your reply. With sincere regards Roger Bentley - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: failed to build aoo420 dev on win32
The "assertion failed" messageboxes problem (#i126918#) is fixed in trunk now. You no longer need --disable-unit-tests, and are better off with the unit tests enabled. Regards Damjan On Sun, Apr 10, 2016 at 2:28 PM, Oliver Brinzing wrote: > Hi Patricia, > > thanks for your build settings. > Did you manage to build aoo420 debug version? > > yesterday i started a new aoo412 debug build with my settings. > after 5 hours the build finished without any problems. > > i tried again with rev 1738357 and failed again... added 4 issues: > > windows build breaks in module crashrep - Assertion Failed > https://bz.apache.org/ooo/show_bug.cgi?id=126918 > > windows build breaks in module connectivity/source/parse/sqliterator.cxx > https://bz.apache.org/ooo/show_bug.cgi?id=126917 > > windows build breaks in module formula > https://bz.apache.org/ooo/show_bug.cgi?id=126916 > > windows build breaks in module sc/source/filter/excel - missing #include > > https://bz.apache.org/ooo/show_bug.cgi?id=126919 > > maybe i should try again with " --disable-pch" do not use multiple > parallel processes feature (e.g. build --all -P2 -- -P2) > > Regards > Oliver > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
RE: A Question about Open Office Password Protected Text Documenets
> -Original Message- > From: Damjan Jovanovic [mailto:dam...@apache.org] > Sent: Friday, June 10, 2016 07:29 > To: Apache OO > Subject: Re: A Question about Open Office Password Protected Text > Documenets > > Hi Roger > > If you saved them in OpenOffice's default format, OpenDocument (.odt / > .ods > / .odb etc.), then yes. Password protection is part of the OpenDocument > standard, and should be supported by us and other OpenDocument software > such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The > encryption techniques are all well documented and use common well > established ciphers, hash functions and password strengthening > procedures. > > With long term storage, the problem won't be data becoming inaccessible > due > to encryption (provided you remember your passwords), so much as the > opposite problem, of data becoming too easily accessible, since older > versions of OpenDocument used weaker encryption ciphers, potentially > making > document encryption too easy to crack by future weaknesses discovered in > those ciphers and with more powerful computers in the future. [orcmid] There is a misunderstanding here. The problem of using the latest-and-greatest (i.e, based on AES) supported encryptions is that older versions of software won't be able to open it and versions that have not upgraded their support or for which there is an interoperability defect won't open it either. We ran into this recently where users of Mac OSX could no longer open some password-protected files. It is not in our power to offer a guarantee about this. At the moment, the basic cryptography used since ODF 1.0 is working. There is no way that the project can assert that this will apply in perpetuity and that software to accomplish it will always be available. That is beyond our means. Finally, the use of better hash algorithms and AES as a check-box item do *not* eliminate the known exposure of ODF documents to cryptographic attack and decryption by an adversary. ODF encryption should *never* be used for highly-confidential documents, especially files subject to security-classification regimes of governments or other entities. I don't belief any such agency would permit ODF encryption to be used; encryption would be accomplished by other means. The reasons for that are quite simple: 1. All ODF encryption is password-based. That is the greatest single vulnerability, especially if the same password is used on multiple documents. There are extremely well-known and highly-available means for attacking encryptions using memorable passwords. This vulnerability trumps everything. This is something the software does not control and cannot mitigate much. Note that advertised password-recovery software *does* succeed against password-protected ODF documents on occasion. The advances in computer performance (especially graphics processors) ensure that the number of passwords that are defeated by such software will only increase. 2. Because the encryption is of a static, persistent document, the attack can be conducted off-line for a sustained time and using coordinated crowd-sourced attacks. Advances in technology have neutralized the measures used to make attacking of the password computationally difficult. This means that documents retaining long-duration secrets are the most vulnerable if not adequately protected against disclosure. 3. The particular encryption approach (not the low-level choice of the stream-level encryption algorithm) leaks information about the original ODF document to the point where some unencrypted information may be determined by means other than actually having to decrypt it. That revelation can be used to expedite attack on the password used for the unknown parts. As a final thought. It is revealing that Microsoft Office will not produce ODF documents that are saved with a password, although it will otherwise support ODF format. In addition, the software refuses to open such documents, although it certainly could go that far, in principle. So there is no means to rescue password-saved ODF documents in the most widely-available ODF-supporting software on the planet. - Dennis > > Regards > Damjan > > On Fri, Jun 10, 2016 at 3:42 PM, Roger Bentley > > wrote: > > > Dear Sir/Madam > > > > I have a large number of important documents that I have created over > the > > years in Open Office, which were created as password protected > documents. > > > > Is there any likelihood in the future of any ‘redundancy’ or suchlike > > where these documents would be no longer accessible by future then > current > > software etc? Or will the files always remain safe, in that there > will > > always be an Open Office allied program capable of unlocking their > password > > protected format? > > > > I will be very grateful of your reply. > > > > With sincere regards > > > > Roger Bentley -
RE: A Question about Open Office Password Protected Text Documenets
Roger wrote: >Is there any likelihood in the future of any ‘redundancy’ or suchlike where >these documents would be no longer accessible by future then current software >etc? The presence or absence of a specific feature or function being on the roadmap, does not preclude it from being in a future version of the program. Ideally, there will at least one version of a future program that can read/write passwords created by the current algorithm, and by the proposed/future password algorithm. >in that there will always be an Open Office allied program capable of >unlocking their password protected format? In as much as there is off the shelf software, that is not related to OpenOffice.org, that can read/write passwords created using either the current algorithm, and the former algorithm, I'm fairly confident that any future algorithm changes to password creation, will be incorporated into that off the shelf non-OOo related software. {That the software is available, does not mean that it will display the password, within a human lifetime.} # >From a security perspective, the password protection offered by LibreOffice, Apache Open Office, etc, is roughly equivalent to closing the door and windows of a house. jonathon - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: A Question about Open Office Password Protected Text Documenets
I forgot something important. By default, Apache OpenOffice, as recently as AOO 4.1.2, does *not* use any encryption methods other than those that have been used since ODF 1.0 in 2005. So statements about more-advanced methods do not apply for AOO. I believe AOO will accept (some of) the additional parameters defined for encrypted documents with ODF 1.2, but AOO does not produce such encryptions on documents saved-with-password. - Dennis CONFIRMATION I created a simple saved-with-password .odt using AOO 4.1.2 Writer. My options for this were with Tools > Options > Load/Save > General > ODF format version > 1.2 extended (recommended). When I specified Save with Password, there are no options to choose anything with regard to how that is done. When I inspected the .odt via Zip, the manifest.xml reveals the following about encryption of the first file in the manifest: This is the default approach since ODF 1.0. I was able to open this document in both AOO 4.1.2 (with the password I created), and also in LibreOffice 5.0.0. I resaved the document from LibreOffice into a new file, reusing the same password. I was able to open that document in AOO 4.1.2 with that password too. The LibreOffice 5.0.0 encryption is different. Here is how the manifest.xml in the LibreOffice saved file reports the encryption parameters for the same document part as above: http://www.w3.org/2001/04/xmlenc#aes256-cbc"; manifest:initialisation-vector="6b3kaGTPf2NojfuqUuWB0Q=="/> http://www.w3.org/2000/09/xmldsig#sha256"; manifest:key-size="32"/> The differences are mainly use of SHA256 instead of SHA1 and the use of AES256 instead of Blowfish. The most-vulnerable aspects are the manifest:key-derivation technique and the manifest:start-key-generation. The manifest:iteration-count of 1024 is negligible. Oh, and the unencrypted stream, Configurations2/accelerator/current.xml, is completely known already. > -Original Message- > From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] > Sent: Friday, June 10, 2016 10:55 > To: dev@openoffice.apache.org > Subject: RE: A Question about Open Office Password Protected Text > Documenets > > > > > -Original Message- > > From: Damjan Jovanovic [mailto:dam...@apache.org] > > Sent: Friday, June 10, 2016 07:29 > > To: Apache OO > > Subject: Re: A Question about Open Office Password Protected Text > > Documenets > > > > Hi Roger > > > > If you saved them in OpenOffice's default format, OpenDocument (.odt / > > .ods > > / .odb etc.), then yes. Password protection is part of the > OpenDocument > > standard, and should be supported by us and other OpenDocument > software > > such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The > > encryption techniques are all well documented and use common well > > established ciphers, hash functions and password strengthening > > procedures. > > > > With long term storage, the problem won't be data becoming > inaccessible > > due > > to encryption (provided you remember your passwords), so much as the > > opposite problem, of data becoming too easily accessible, since older > > versions of OpenDocument used weaker encryption ciphers, potentially > > making > > document encryption too easy to crack by future weaknesses discovered > in > > those ciphers and with more powerful computers in the future. > [orcmid] > > There is a misunderstanding here. The problem of using the latest-and- > greatest (i.e, based on AES) supported encryptions is that older > versions of software won't be able to open it and versions that have not > upgraded their support or for which there is an interoperability defect > won't open it either. > > We ran into this recently where users of Mac OSX could no longer open > some password-protected files. > > It is not in our power to offer a guarantee about this. At the moment, > the basic cryptography used since ODF 1.0 is working. There is no way > that the project can assert that this will apply in perpetuity and that > software to accomplish it will always be available. That is beyond our > means. > > Finally, the use of better hash algorithms and AES as a check-box item > do *not* eliminate the known exposure of ODF documents to cryptographic > attack and decryption by an adversary. ODF encryption should *never* be > used for highly-confidential documents, especially files subject to > security-classification regimes of governments or other entities. I > don't belief any such agency would permit ODF encryption to be used; > encryption would be accomplished by other means. > > The reasons for that are quite simple: > > 1. All ODF encryption is password-based. That is the greatest single > vulnerability, especially if the same password is used on multiple > documents. There are extremely well-known
RE: A Question about Open Office Password Protected Text Documenets
> -Original Message- > From: toki [mailto:toki.kant...@gmail.com] > Sent: Friday, June 10, 2016 11:49 > To: dev@openoffice.apache.org > Subject: RE: A Question about Open Office Password Protected Text > Documenets [ ... ] > # > > From a security perspective, the password protection offered by > LibreOffice, Apache Open Office, etc, is roughly equivalent to closing > the door and windows of a house. > > jonathon > [orcmid] Well-said. - Dennis > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A Question about Open Office Password Protected Text Documents
Dear Mr Jovanovic Thank you very much for your email. Your reply is greatly appreciated. Thank you. With sincere regards Roger Bentley -Original Message- From: Damjan Jovanovic Sent: Friday, June 10, 2016 3:29 PM To: Apache OO Subject: Re: A Question about Open Office Password Protected Text Documenets Hi Roger If you saved them in OpenOffice's default format, OpenDocument (.odt / .ods / .odb etc.), then yes. Password protection is part of the OpenDocument standard, and should be supported by us and other OpenDocument software such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The encryption techniques are all well documented and use common well established ciphers, hash functions and password strengthening procedures. With long term storage, the problem won't be data becoming inaccessible due to encryption (provided you remember your passwords), so much as the opposite problem, of data becoming too easily accessible, since older versions of OpenDocument used weaker encryption ciphers, potentially making document encryption too easy to crack by future weaknesses discovered in those ciphers and with more powerful computers in the future. Regards Damjan On Fri, Jun 10, 2016 at 3:42 PM, Roger Bentley wrote: Dear Sir/Madam I have a large number of important documents that I have created over the years in Open Office, which were created as password protected documents. Is there any likelihood in the future of any ‘redundancy’ or suchlike where these documents would be no longer accessible by future then current software etc? Or will the files always remain safe, in that there will always be an Open Office allied program capable of unlocking their password protected format? I will be very grateful of your reply. With sincere regards Roger Bentley - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A Question about Open Office Password Protected Text Documents
Dear Ms Shanahan Thank you very much for your email and comments. They are greatly appreciated. Yours sincerely Roger Bentley -Original Message- From: Patricia Shanahan Sent: Friday, June 10, 2016 3:51 PM To: dev@openoffice.apache.org Subject: Re: A Question about Open Office Password Protected Text Documents That said, if I had a set of business-critical documents, I would test some sample documents at each major OS, hardware, or office software upgrade. Before decommissioning the last instance of the old system, load and read a few sample documents on the new system. If there is a problem, use the old system to convert to an updated format. On 6/10/2016 7:29 AM, Damjan Jovanovic wrote: Hi Roger If you saved them in OpenOffice's default format, OpenDocument (.odt / .ods / .odb etc.), then yes. Password protection is part of the OpenDocument standard, and should be supported by us and other OpenDocument software such as AbiWord, Gnumeric, Microsoft Office, etc. for a long time. The encryption techniques are all well documented and use common well established ciphers, hash functions and password strengthening procedures. With long term storage, the problem won't be data becoming inaccessible due to encryption (provided you remember your passwords), so much as the opposite problem, of data becoming too easily accessible, since older versions of OpenDocument used weaker encryption ciphers, potentially making document encryption too easy to crack by future weaknesses discovered in those ciphers and with more powerful computers in the future. Regards Damjan On Fri, Jun 10, 2016 at 3:42 PM, Roger Bentley wrote: Dear Sir/Madam I have a large number of important documents that I have created over the years in Open Office, which were created as password protected documents. Is there any likelihood in the future of any ‘redundancy’ or suchlike where these documents would be no longer accessible by future then current software etc? Or will the files always remain safe, in that there will always be an Open Office allied program capable of unlocking their password protected format? I will be very grateful of your reply. With sincere regards Roger Bentley - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: failed to build aoo420 dev on win32
Hi Damjan, thanks for fixing the two build breakers. i started a debug build 3 hours ago i have 2 errors till now: >> windows build breaks in module formula >> https://bz.apache.org/ooo/show_bug.cgi?id=126916 and a new one in module "extensions", source/activex/main C:\build_tmp\trunk\main\solver\420\wntmsci12\inc\osl/endian.h(160) : fatal error C1189: #error : undetermined endianness dmake: Error code 2, while making '../../../wntmsci12/slo/x64/so_activex.obj' Regards Oliver -- error in module "extensions", source/activex/main : && PATH=/cygdrive/c/build_tmp/trunk/main/solver/420/wntmsci12/bin${PATH:+:${PATH}} C:/build_tmp/trunk/main/solver/420/wntmsci12/bin/makedepend -f - -p../../../wntmsci12/res -o.res -DWNT -DWNT -DNT351 -DMSC -DM1500 -DINTEL -D_STLP_DEBUG -D_X86_=1 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -DFULL_DESK -DBOOST_MEM_FN_ENABLE_CDECL -D_MT -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -D_WIN32_IE=0x0500 -DCPPU_ENV=msci -DSUPD=420 -DDEBUG -DDBG_UTIL -DOSL_DEBUG_LEVEL=2 -DCUI -DSOLAR_JAVA -DDLLPOSTFIX= -I. -I../../../inc -I../inc -I../../../WIN/inc -I../../../wntmsci12/inc -IC:/build_tmp/trunk/main/solenv/inc so_activex.rc >> ../../../wntmsci12/misc/so_activex.dprc cat ../../../wntmsci12/res/so_activex.res > ../../../wntmsci12/misc/so_activex.res Making:so_activex.dll link /MACHINE:IX86 /IGNORE:4102 /IGNORE:4197 @C:/build/cygwin/tmp/mk4lyHC8 if [ -f ../../../wntmsci12/bin/so_activex.dll.manifest ] ; then mt.exe -manifest ../../../wntmsci12/bin/so_activex.dll.manifest -outputresource:../../../wntmsci12/bin/so_activex.dll\;2 ; fi if [ -f ../../../wntmsci12/bin/so_activex.dll.manifest ] ; then /bin/rm -f ../../../wntmsci12/bin/so_activex.dll.manifest ; fi if [ -f ../../../wntmsci12/bin/so_activex.dll.tmanifest ] ; then /bin/rm -f ../../../wntmsci12/bin/so_activex.dll.tmanifest ; fi Microsoft (R) Incremental Linker Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. -safeseh -nxcompat -dynamicbase -NODEFAULTLIB -DEBUG -DEBUG -safeseh -nxcompat -dynamicbase /SUBSYSTEM:CONSOLE /DLL -out:../../../wntmsci12/bin/so_activex.dll -map:../../../wntmsci12/misc/so_activex.map -def:so_activex.def -implib:../../../wntmsci12/lib/iso_activex_t1.lib ../../../wntmsci12/slo/so_activex.obj ../../../wntmsci12/slo/SOActiveX.obj ../../../wntmsci12/slo/SOComWindowPeer.obj ../../../wntmsci12/slo/SODispatchInterceptor.obj ../../../wntmsci12/slo/SOActionsApproval.obj ../../../wntmsci12/slo/StdAfx2.obj uuid.lib advapi32.lib ole32.lib oleaut32.lib gdi32.lib urlmon.lib shlwapi.lib C:/WinDDK/760016~1.1/lib/ATL/i386/atls.lib C:/WinDDK/760016~1.1/lib/ATL/i386/atlthunk.lib msvcrt.lib msvcprt.lib kernel32.lib user32.lib oldnames.lib ../../../wntmsci12/misc/so_activex.res -- Making: ../../../wntmsci12/slo/x64/so_activex.obj so_activex.def : warning LNK4222: exported symbol 'DllCanUnloadNow' should not be assigned an ordinal so_activex.def : warning LNK4222: exported symbol 'DllGetClassObject' should not be assigned an ordinal so_activex.def : warning LNK4222: exported symbol 'DllRegisterServer' should not be assigned an ordinal so_activex.def : warning LNK4222: exported symbol 'DllUnregisterServer' should not be assigned an ordinal Creating library ../../../wntmsci12/lib/iso_activex_t1.lib and object ../../../wntmsci12/lib/iso_activex_t1.exp mkdir.exe ../../../wntmsci12/slo/x64/ C:/PROGRA~2/MICROS~1.0/VC/bin/amd64/cl.exe -c -nologo -Gs -Zm500 -Zc:wchar_t- -GR -Zi -Fd../../../wntmsci12/misc/x64/so_activex.pdb -Ob1 -I. -I../../../wntmsci12/inc/so_activex -IC:/WinDDK/760016~1.1/inc/atl71 -I../../../wntmsci12/misc -I../inc -I../../../inc/pch -I../../../inc -I../../../WIN/inc -I../../../wntmsci12/inc -I. -IC:/build_tmp/trunk/main/solver/420/wntmsci12/incdont_use_stl -IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc/external -IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc -IC:/build_tmp/trunk/main/solenv/wntmsci12/inc -IC:/build_tmp/trunk/main/solenv/inc -IC:/build_tmp/trunk/main/res -IC:/build_tmp/trunk/main/tools/inc -IC:/build_tmp/trunk/main/comphelper/inc -IC:/PROGRA~2/Java/JDK17~1.0/include/win32 -IC:/PROGRA~2/Java/JDK17~1.0/include -IC:/PROGRA~1/MICROS~1/Windows/v7.0/include -IC:/PROGRA~2/MICROS~1.0/VC/include -IC:/PROGRA~2/MICROS~1/include -IC:/PROGRA~2/MICROS~1/include -IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc/offuh -I. -I../../../res -I. -MT -DWIN32 -D_AMD64_=1 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -DDEBUG -DWNT -DWNT -DNT351 -DMSC -DM1500 -DINTEL -D_STLP_DEBUG -D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -DFULL_DESK -DBOOST_MEM_FN_ENABLE_CDECL -D_MT -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 -D_WIN32_IE=0x0500 -DCPPU_ENV=msci -DSUPD=420 -DDEBUG -DDBG_UTIL -DOSL_DEBUG_LEVEL=2 -DCUI -DSOLAR_JAVA -D_MT -D_DLL -D_MT -D_DLL -DEXCEPTIONS_OFF -Fo../../../wntmsci
Re: failed to build aoo420 dev on win32
On Fri, Jun 10, 2016 at 10:03 PM, Oliver Brinzing wrote: > Hi Damjan, > > thanks for fixing the two build breakers. i started a debug build 3 hours > ago > i have 2 errors till now: > Hi Oliver > >> windows build breaks in module formula > >> https://bz.apache.org/ooo/show_bug.cgi?id=126916 > > I've attached a possible patch for this, but won't be able to test it for a while. Does it work for you? > and a new one in module "extensions", source/activex/main > > C:\build_tmp\trunk\main\solver\420\wntmsci12\inc\osl/endian.h(160) : fatal > error C1189: #error : undetermined endianness > dmake: Error code 2, while making > '../../../wntmsci12/slo/x64/so_activex.obj' > > Are you building on x64? AOO only supports 32 bit Windows. > Regards > Oliver > > -- > > error in module "extensions", source/activex/main > > : && > > PATH=/cygdrive/c/build_tmp/trunk/main/solver/420/wntmsci12/bin${PATH:+:${PATH}} > C:/build_tmp/trunk/main/solver/420/wntmsci12/bin/makedepend -f - > -p../../../wntmsci12/res -o.res -DWNT -DWNT -DNT351 -DMSC -DM1500 -DINTEL > -D_STLP_DEBUG -D_X86_=1 -D_CRT_SECURE_NO_DEPRECATE > -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -DFULL_DESK > -DBOOST_MEM_FN_ENABLE_CDECL -D_MT -DWINVER=0x0500 -D_WIN32_WINNT=0x0500 > -D_WIN32_IE=0x0500 -DCPPU_ENV=msci -DSUPD=420 -DDEBUG -DDBG_UTIL > -DOSL_DEBUG_LEVEL=2 -DCUI -DSOLAR_JAVA -DDLLPOSTFIX= -I. -I../../../inc > -I../inc -I../../../WIN/inc -I../../../wntmsci12/inc > -IC:/build_tmp/trunk/main/solenv/inc so_activex.rc >> > ../../../wntmsci12/misc/so_activex.dprc > cat ../../../wntmsci12/res/so_activex.res > > ../../../wntmsci12/misc/so_activex.res > Making:so_activex.dll > link /MACHINE:IX86 /IGNORE:4102 /IGNORE:4197 @C:/build/cygwin/tmp/mk4lyHC8 > if [ -f ../../../wntmsci12/bin/so_activex.dll.manifest ] ; then mt.exe > -manifest ../../../wntmsci12/bin/so_activex.dll.manifest > -outputresource:../../../wntmsci12/bin/so_activex.dll\;2 ; fi > if [ -f ../../../wntmsci12/bin/so_activex.dll.manifest ] ; then /bin/rm -f > ../../../wntmsci12/bin/so_activex.dll.manifest ; fi > if [ -f ../../../wntmsci12/bin/so_activex.dll.tmanifest ] ; then /bin/rm > -f ../../../wntmsci12/bin/so_activex.dll.tmanifest ; fi > Microsoft (R) Incremental Linker Version 9.00.30729.01 > Copyright (C) Microsoft Corporation. All rights reserved. > -safeseh -nxcompat -dynamicbase -NODEFAULTLIB -DEBUG -DEBUG -safeseh > -nxcompat -dynamicbase /SUBSYSTEM:CONSOLE /DLL > -out:../../../wntmsci12/bin/so_activex.dll > -map:../../../wntmsci12/misc/so_activex.map -def:so_activex.def > -implib:../../../wntmsci12/lib/iso_activex_t1.lib > ../../../wntmsci12/slo/so_activex.obj ../../../wntmsci12/slo/SOActiveX.obj > ../../../wntmsci12/slo/SOComWindowPeer.obj > ../../../wntmsci12/slo/SODispatchInterceptor.obj > ../../../wntmsci12/slo/SOActionsApproval.obj > ../../../wntmsci12/slo/StdAfx2.obj uuid.lib advapi32.lib ole32.lib > oleaut32.lib gdi32.lib urlmon.lib shlwapi.lib > C:/WinDDK/760016~1.1/lib/ATL/i386/atls.lib > C:/WinDDK/760016~1.1/lib/ATL/i386/atlthunk.lib msvcrt.lib msvcprt.lib > kernel32.lib user32.lib oldnames.lib ../../../wntmsci12/misc/so_activex.res > -- > Making: ../../../wntmsci12/slo/x64/so_activex.obj > so_activex.def : warning LNK4222: exported symbol 'DllCanUnloadNow' should > not be assigned an ordinal > so_activex.def : warning LNK4222: exported symbol 'DllGetClassObject' > should not be assigned an ordinal > so_activex.def : warning LNK4222: exported symbol 'DllRegisterServer' > should not be assigned an ordinal > so_activex.def : warning LNK4222: exported symbol 'DllUnregisterServer' > should not be assigned an ordinal >Creating library ../../../wntmsci12/lib/iso_activex_t1.lib and object > ../../../wntmsci12/lib/iso_activex_t1.exp > mkdir.exe ../../../wntmsci12/slo/x64/ > C:/PROGRA~2/MICROS~1.0/VC/bin/amd64/cl.exe -c -nologo -Gs -Zm500 > -Zc:wchar_t- -GR -Zi -Fd../../../wntmsci12/misc/x64/so_activex.pdb -Ob1 > -I. -I../../../wntmsci12/inc/so_activex -IC:/WinDDK/760016~1.1/inc/atl71 > -I../../../wntmsci12/misc -I../inc -I../../../inc/pch -I../../../inc > -I../../../WIN/inc -I../../../wntmsci12/inc -I. > -IC:/build_tmp/trunk/main/solver/420/wntmsci12/incdont_use_stl > -IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc/external > -IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc > -IC:/build_tmp/trunk/main/solenv/wntmsci12/inc > -IC:/build_tmp/trunk/main/solenv/inc -IC:/build_tmp/trunk/main/res > -IC:/build_tmp/trunk/main/tools/inc > -IC:/build_tmp/trunk/main/comphelper/inc > -IC:/PROGRA~2/Java/JDK17~1.0/include/win32 > -IC:/PROGRA~2/Java/JDK17~1.0/include > -IC:/PROGRA~1/MICROS~1/Windows/v7.0/include > -IC:/PROGRA~2/MICROS~1.0/VC/include -IC:/PROGRA~2/MICROS~1/include > -IC:/PROGRA~2/MICROS~1/include > -IC:/build_tmp/trunk/main/solver/420/wntmsci12/inc/offuh -I. -I../../../res > -I. -MT -DWIN32 -D_AMD64_=1 -D_CRT_SECURE_NO_DEPRECATE > -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -DDEBUG -DWNT > -DWNT -DNT351