Re: sot module build failures with recent gcc
Dear All, On Tue, Aug 01, 2023 at 11:57:09AM +0200, Peter Kovacs wrote: > hello Don, > > were you able to look into this, or the freeBsd volunteer. > > I can try to put together a report for gcc if you still like that to be > done. If you can carve out the necessary bits, and only them, and reproduce the problem, then it would be great IMHO. Don, do we know if clang compiles correctly? For what it's worth, I tried to work around this bug in this PR for AOO41X: https://github.com/apache/openoffice/pull/198 > Am 01.04.23 um 20:12 schrieb Arrigo Marchiori: > > Hello Don, All, > > > > On Wed, Mar 29, 2023 at 11:58:06PM -0700, Don Lewis wrote: > > > > > A FreeBSD user is trying to unbreak the ppc64 build and ran into an > > > issue with the sot module. I dig into it pretty deeply and it looks to > > > me like a gcc bug. It's reproducable in amd64. It seems to affect > > > gcc10, gcc11, and gcc12 builds. The build failure does not happen with > > > gcc9. > > > > > > It is not limited to FreeBSD. I get the same failure on Debian > > > bullseye: > > > cc --version > > > cc (Debian 10.2.1-6) 10.2.1 20210110 > > > Copyright (C) 2020 Free Software Foundation, Inc. > > > This is free software; see the source for copying conditions. There is NO > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > > > PURPOSE. > > > > > > [ build LNK ] Library/libsot.so > > > /usr/bin/ld: > > > /home/dl/aoo/openoffice/main/solver/4111/unxlngx6.pro/workdir/CxxObject/sot/source/sdstor/ucbstorage.o: > > > in function `UCBStorage_Impl::Init()': > > > ucbstorage.cxx:(.text+0x72b4): undefined reference to `non-virtual thunk > > > to cppu::WeakImplHelper1::acquire()' > > > collect2: error: ld returned 1 exit status > > > > > > > > > The problem appears to be that gcc is getting confused when compiling > > > line 1884 of ucbstorage.cxx. It ends up trying to call the thunk to the > > > acquire() method of a non-existent class. That thunk isn't defined, so > > > the linker bombs on the undefined symbol. > > I reproduced it with OpenSUSE Linux Leap 15.4, using the provided gcc-10. > > > > However, the problem seems to be at line 1879: > > > > > > com::sun::star::uno::Reference < ::com::sun::star::io::XInputStream > > > > > xInputStream( pHelper ); > > It seems to compile if we split it as follows: > > > > > > com::sun::star::uno::Reference < ::com::sun::star::io::XInputStream > > > > > xInputStream; > > > > xInputStream = pHelper; > > This _should_ work as it is how method > > Reference UCBStorageStream_Impl::GetXInputStream() > > does: it returns an instance of Reference on which > > it calls calls operator= with a OInputStreamWrapper > > > > I have no idea how to test this, though. > > > > Can you please verify if the above restores compilation? > > > > Best regards, -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
[PR] Allow compilation of AOO41X under Ubuntu Jammy (GCC 11) [openoffice]
ardovm opened a new pull request, #198: URL: https://github.com/apache/openoffice/pull/198 The AOO41X branch does not seem to build on Ubuntu 22.04 "Jammy". The purpose of this pull request is to gather and review the modifications that make AOO41X build again. The edits mostly consist of: 1. disabling -Werror compilation flags, because newer GCC versions find more warning than previous ones; 2. fixing compilation where necessary as per [this thread of the dev@ mailing list](https://lists.apache.org/thread/gbfm2djykqk9ksqw22vobklf6d4lm0ly) The edit to the boost module was cherry-picked from trunk. This branch shall be tested on Ubuntu Jammy, but also on other platforms, in order to make sure that we are not breaking anything. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: odf-1.3 branch pushed, progress update
On Tue, Jan 16, 2024 at 7:10 PM Marcus wrote: > Am 16.01.24 um 17:50 schrieb Damjan Jovanovic: > > I've now pushed my "odf-1.3" branch upstream, which has some initial ODF > > 1.3 compatibility patches, a patch adding a new constraint for the > RECEIVED > > function, and another to only make the upgrade dialog appear when > version > > > 1.3. > > > > There are 3 useful parts to the ODF 1.3 specification, part 2 dealing > with > > packaging, part 3 with the OpenDocument schema, and part 4 with > > OpenFormula. So far I've mostly been developing part 4. Of the 34 issues > > under part 4, 20 are now complete, which means part 4 development is > > already 59% complete. > > from zero to 59% in a few days. That's great.! :-) > :-) > > Would anyone like to help? > > If you mean coding, then you have to teach me C++ first. ;-P > Honestly, here I won't be of any help. Other things depend. > For my latest change, which added support for weekday types 11-17 to the WEEKDAY function, those new types should probably be documented in the "OpenOffice Help" page for WEEKDAY. Can someone update those? > > Before we bring this into a release, we should discuss and define how we > want or should offer the ODF 1.3 support. > > My suggestion: > > Instead of putting this as a selectable option in the Save dialog, we > should add this to the other ODF version parts (see menu "Tools - > Options - Load/Save - General - Default file format and ODF settings"). > Yes, I still need to add that. > I don't know how loading is working. But I would expect that the header > data is read and the ODF version is recognized with some magic numbers. > If you unzip an OpenDocument file, there are office:version="1.3" attributes on at least content.xml, meta.xml, settings.xml, and styles.xml. Damjan
Re: odf-1.3 branch pushed, progress update
Am 16.01.24 um 17:50 schrieb Damjan Jovanovic: I've now pushed my "odf-1.3" branch upstream, which has some initial ODF 1.3 compatibility patches, a patch adding a new constraint for the RECEIVED function, and another to only make the upgrade dialog appear when version > 1.3. There are 3 useful parts to the ODF 1.3 specification, part 2 dealing with packaging, part 3 with the OpenDocument schema, and part 4 with OpenFormula. So far I've mostly been developing part 4. Of the 34 issues under part 4, 20 are now complete, which means part 4 development is already 59% complete. from zero to 59% in a few days. That's great.! :-) So far only 1 issue needed a code change, and at least 1 more also will, but the impression I get is that the vast majority of changes were made not because ODF 1.3 is hugely different from ODF 1.2, but because parts of ODF 1.2 were wrong or ambiguous and they wanted to fix the specification for the sake of better interoperability with other implementations (probably Microsoft Office). A lot of the design decisions seem to have been made in favour of AOO/LO, standardizing on how we already work, leaving us with little or nothing to change :-). That's interesting. So, when we want to support ODF 1.3 we just need to change / implement little code. That means also that no bigger or many problems should occur. At least this is my hope. Even better. Confluence has been working surprisingly well. :-) Would anyone like to help? If you mean coding, then you have to teach me C++ first. ;-P Honestly, here I won't be of any help. Other things depend. Before we bring this into a release, we should discuss and define how we want or should offer the ODF 1.3 support. My suggestion: Instead of putting this as a selectable option in the Save dialog, we should add this to the other ODF version parts (see menu "Tools - Options - Load/Save - General - Default file format and ODF settings"). I don't know how loading is working. But I would expect that the header data is read and the ODF version is recognized with some magic numbers. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: ODF 1.3 development
Am 16.01.24 um 17:32 schrieb Keith N. McKenna: Marcus wrote: I would like to move the other Wiki content into Confluence as management is better there. However, it's may too much for my free time. Even if you could move it, the mwiki would need to stay active as it does not appear that cwiki has a file upload to use it to distribute or documentation. sure, I don't meant to move everything, so that it is empty. It's more the "normal" documentation on the pages itself. ;-) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: ODF 1.3 development
Hi Keith, On Tue, Jan 16, 2024 at 5:32 PM Keith N. McKenna wrote: > Marcus wrote: > > I would like to move the other Wiki content into Confluence as > > management is better there. However, it's may too much for my free time. > > Even if you could move it, the mwiki would need to stay active as it > does not appear that cwiki has a file upload to use it to distribute or > documentation. > Can I get an example of what you mean please Keith, so I can compare and at least take a look on the cwiki side. Thanks Gav... > Regards > Keith > > >
odf-1.3 branch pushed, progress update
Hi I've now pushed my "odf-1.3" branch upstream, which has some initial ODF 1.3 compatibility patches, a patch adding a new constraint for the RECEIVED function, and another to only make the upgrade dialog appear when version > 1.3. There are 3 useful parts to the ODF 1.3 specification, part 2 dealing with packaging, part 3 with the OpenDocument schema, and part 4 with OpenFormula. So far I've mostly been developing part 4. Of the 34 issues under part 4, 20 are now complete, which means part 4 development is already 59% complete. So far only 1 issue needed a code change, and at least 1 more also will, but the impression I get is that the vast majority of changes were made not because ODF 1.3 is hugely different from ODF 1.2, but because parts of ODF 1.2 were wrong or ambiguous and they wanted to fix the specification for the sake of better interoperability with other implementations (probably Microsoft Office). A lot of the design decisions seem to have been made in favour of AOO/LO, standardizing on how we already work, leaving us with little or nothing to change :-). Of course there is still the lengthy ODF 1.3 part 3 to go through, and ODF 1.3 part 2 will also require some development to add OpenGPG encryption support. Ideally we should also add some unit tests for the new development, but I am not yet sure how best to implement those. Confluence has been working surprisingly well. Would anyone like to help? Regards Damjan
Re: ODF 1.3 development
Marcus wrote: I would like to move the other Wiki content into Confluence as management is better there. However, it's may too much for my free time. Even if you could move it, the mwiki would need to stay active as it does not appear that cwiki has a file upload to use it to distribute or documentation. Regards Keith - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
