Re: C++ standard when building OpenOffice
On 04.11.2019 05:15, Damjan Jovanovic wrote: > Yeah, it has compiler bugs, undocumented linker issues, crashes when built > with Clang due to lack of -fno-enforce-eh-specs support, crash-on-startup > on some Windows installations, porting to new platforms is hard, there are > incompatibilities with Microsoft Visual C++ > static/multithreaded/debug/release library options, it's difficult using > new C++ versions, it has ridiculous build times (7+ hours on Windows), > patches often break the build on some platforms, has all kinds of > platform-specific limitations (eg. no throwing exceptions or passing STL > structures across DLL boundaries), and it's Swiss cheese in terms of > security holes, but C++ is just perfect right? OK, if this is going to be a language war, let me just point out that "competent" isn't a function of the source programming language ... :) -- Brane - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: C++ standard when building OpenOffice
On Mon, Nov 4, 2019 at 3:49 AM Branko Čibej wrote: > On 04.11.2019 02:14, Damjan Jovanovic wrote: > > Thank you for the info. I haven't had good experiences with Boost in my > > Win64 attempts either... > > > > Don, how feasible do you think Go or Rust are, to start using in place of > > C++? > > Really? You'd rewrite code in a completely different language because > you can't figure out a way to select std::auto_ptr or std::unique_ptr > depending on your build environment? > I said "start using" (for new development), not "rewrite". The Mozilla project did something similar, they used Rust to develop their new Servo layout engine, not rewrite the whole of Firefox in it. > > FWIW, both Go and Rust are far more moving targets than C++, but sure, > that's not going to be a problem, eh. > Yeah, it has compiler bugs, undocumented linker issues, crashes when built with Clang due to lack of -fno-enforce-eh-specs support, crash-on-startup on some Windows installations, porting to new platforms is hard, there are incompatibilities with Microsoft Visual C++ static/multithreaded/debug/release library options, it's difficult using new C++ versions, it has ridiculous build times (7+ hours on Windows), patches often break the build on some platforms, has all kinds of platform-specific limitations (eg. no throwing exceptions or passing STL structures across DLL boundaries), and it's Swiss cheese in terms of security holes, but C++ is just perfect right? The reason we haven't made more progress in AOO and added more features, is because we're too busy babysitting C++. If AOO was to be redeveloped, I would use C, and supplement it with higher-level memory-safe languages (NEVER C++).
Re: C++ standard when building OpenOffice
On 11/3/2019 5:49 PM, Branko Čibej wrote: On 04.11.2019 02:14, Damjan Jovanovic wrote: Thank you for the info. I haven't had good experiences with Boost in my Win64 attempts either... Don, how feasible do you think Go or Rust are, to start using in place of C++? Really? You'd rewrite code in a completely different language because you can't figure out a way to select std::auto_ptr or std::unique_ptr depending on your build environment? I think there are more reasons than that for wanting to move away from C++, but I do not think it is feasible. The total size of files whose names end in ".cxx" is 5,410,709 lines. Under any reasonable productivity assumptions, that would take person-decades to convert. Maybe a less ambitious project would be feasible. Pick a fairly recent version of the C++ standard and STL that is popular - lots of existing code written to that version of the standard so compilers and libraries are likely to support it for some time into the future. Aim to convert to that, so we can use system supplied headers etc. FWIW, both Go and Rust are far more moving targets than C++, but sure, that's not going to be a problem, eh. -- Brane On Mon, Nov 4, 2019 at 1:08 AM Don Lewis wrote: On 3 Nov, Don Lewis wrote: For much of our history, until fairly recently, the versions of gcc that we used defaulted to -std=gnu++98 when compiiling C++ code. When FreeBSD on i386 and amd64 switched from gcc to clang, it also defaulted to -std=gnu++98. Clang has been C++11 compliant from version 3.3 onwards. Around the time of the switch, I added the -DHAVE_STL_INCLUDE_PATH compiler flag so that clang would use it's own STL include files instead of the boost TR1 includes. Clang was perfectly happy using its own STL include files even though they were not part of C++98, only C++11. Later on, when clang 6 changed the default to gnu++14, the build generated tons warning and some number of errors. To work around this, I added the -std=gnu++98 compiler flag to force the old mode. FreeBSD on powerpc still uses gcc and it recently came to my attention that the build was broken there. The FreeBSD port of AOO to powerpc does not use -DHAVE_STL_INCLUDE_PATH, so it was falling back to the boost TR1 headers. The FreeBSD port uses the system boost, and recent versions of boost have dropped TR1 support. To work around that, I tried enabling -DHAVE_STL_INCLUDE_PATH to use the gcc C++ headers. This failed badly because the gcc STL headers check to see if the compilation mode is C++11 or better and immediately error out of this is not the case. Switching the compilation mode to c++11 results in the warning and error spew mentioned above. I tried modifying the stlport headers to include the gcc TR1 headers in gnu++98 mode. That worked better, but I still got some mysterious C++ errors that I was not able to figure out. My next attempt will be to try the boost non-TR1 headers. That was a dead end. Recent boost appears to assume that the STL headers are provided by the system. I'll probably have to switch back to bundled boost and use its TR1 headers. - 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 -- This email has been checked for viruses by AVG. https://www.avg.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: C++ standard when building OpenOffice
On 04.11.2019 02:14, Damjan Jovanovic wrote: > Thank you for the info. I haven't had good experiences with Boost in my > Win64 attempts either... > > Don, how feasible do you think Go or Rust are, to start using in place of > C++? Really? You'd rewrite code in a completely different language because you can't figure out a way to select std::auto_ptr or std::unique_ptr depending on your build environment? FWIW, both Go and Rust are far more moving targets than C++, but sure, that's not going to be a problem, eh. -- Brane > On Mon, Nov 4, 2019 at 1:08 AM Don Lewis wrote: > >> On 3 Nov, Don Lewis wrote: >>> For much of our history, until fairly recently, the versions of gcc that >>> we used defaulted to -std=gnu++98 when compiiling C++ code. >>> >>> When FreeBSD on i386 and amd64 switched from gcc to clang, it also >>> defaulted to -std=gnu++98. Clang has been C++11 compliant from version >>> 3.3 onwards. Around the time of the switch, I added the >>> -DHAVE_STL_INCLUDE_PATH compiler flag so that clang would use it's own >>> STL include files instead of the boost TR1 includes. Clang was >>> perfectly happy using its own STL include files even though they were >>> not part of C++98, only C++11. >>> >>> Later on, when clang 6 changed the default to gnu++14, the build >>> generated tons warning and some number of errors. To work around this, >>> I added the -std=gnu++98 compiler flag to force the old mode. >>> >>> FreeBSD on powerpc still uses gcc and it recently came to my attention >>> that the build was broken there. The FreeBSD port of AOO to powerpc >>> does not use -DHAVE_STL_INCLUDE_PATH, so it was falling back to the >>> boost TR1 headers. The FreeBSD port uses the system boost, and recent >>> versions of boost have dropped TR1 support. To work around that, I >>> tried enabling -DHAVE_STL_INCLUDE_PATH to use the gcc C++ headers. This >>> failed badly because the gcc STL headers check to see if the compilation >>> mode is C++11 or better and immediately error out of this is not the >>> case. Switching the compilation mode to c++11 results in the warning >>> and error spew mentioned above. I tried modifying the stlport headers >>> to include the gcc TR1 headers in gnu++98 mode. That worked better, but >>> I still got some mysterious C++ errors that I was not able to figure >>> out. My next attempt will be to try the boost non-TR1 headers. >> That was a dead end. Recent boost appears to assume that the STL headers >> are provided by the system. I'll probably have to switch back to >> bundled boost and use its TR1 headers. >> >> >> - >> 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: C++ standard when building OpenOffice
Thank you for the info. I haven't had good experiences with Boost in my Win64 attempts either... Don, how feasible do you think Go or Rust are, to start using in place of C++? On Mon, Nov 4, 2019 at 1:08 AM Don Lewis wrote: > On 3 Nov, Don Lewis wrote: > > For much of our history, until fairly recently, the versions of gcc that > > we used defaulted to -std=gnu++98 when compiiling C++ code. > > > > When FreeBSD on i386 and amd64 switched from gcc to clang, it also > > defaulted to -std=gnu++98. Clang has been C++11 compliant from version > > 3.3 onwards. Around the time of the switch, I added the > > -DHAVE_STL_INCLUDE_PATH compiler flag so that clang would use it's own > > STL include files instead of the boost TR1 includes. Clang was > > perfectly happy using its own STL include files even though they were > > not part of C++98, only C++11. > > > > Later on, when clang 6 changed the default to gnu++14, the build > > generated tons warning and some number of errors. To work around this, > > I added the -std=gnu++98 compiler flag to force the old mode. > > > > FreeBSD on powerpc still uses gcc and it recently came to my attention > > that the build was broken there. The FreeBSD port of AOO to powerpc > > does not use -DHAVE_STL_INCLUDE_PATH, so it was falling back to the > > boost TR1 headers. The FreeBSD port uses the system boost, and recent > > versions of boost have dropped TR1 support. To work around that, I > > tried enabling -DHAVE_STL_INCLUDE_PATH to use the gcc C++ headers. This > > failed badly because the gcc STL headers check to see if the compilation > > mode is C++11 or better and immediately error out of this is not the > > case. Switching the compilation mode to c++11 results in the warning > > and error spew mentioned above. I tried modifying the stlport headers > > to include the gcc TR1 headers in gnu++98 mode. That worked better, but > > I still got some mysterious C++ errors that I was not able to figure > > out. My next attempt will be to try the boost non-TR1 headers. > > That was a dead end. Recent boost appears to assume that the STL headers > are provided by the system. I'll probably have to switch back to > bundled boost and use its TR1 headers. > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: [openoffice] 03/03: Fixes from upstream for newer GCC
On 3 Nov, Ariel Constenla-Haile wrote: > Hi Don, > > On Sat, Nov 2, 2019 at 3:09 PM Don Lewis wrote: >> What version do we need for python 3? > > This page https://devguide.python.org/setup/#windows tells VS 2017. > aoo has a lot of external dependencies, I guess that switching to this > version will force updating to newer versions (something not that > trivial, thinking of ICU for example Upgrading icu is something else that we really need to do. I looked at it once a long time ago and it is definitely not trivial. Probably beyond my skill set. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [openoffice] 03/03: Fixes from upstream for newer GCC
Hi Don, On Sat, Nov 2, 2019 at 3:09 PM Don Lewis wrote: > What version do we need for python 3? This page https://devguide.python.org/setup/#windows tells VS 2017. aoo has a lot of external dependencies, I guess that switching to this version will force updating to newer versions (something not that trivial, thinking of ICU for example). Regards -- Ariel Constenla-Haile La Plata, Buenos Aires Argentina - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: C++ standard when building OpenOffice
On 3 Nov, Don Lewis wrote: > For much of our history, until fairly recently, the versions of gcc that > we used defaulted to -std=gnu++98 when compiiling C++ code. > > When FreeBSD on i386 and amd64 switched from gcc to clang, it also > defaulted to -std=gnu++98. Clang has been C++11 compliant from version > 3.3 onwards. Around the time of the switch, I added the > -DHAVE_STL_INCLUDE_PATH compiler flag so that clang would use it's own > STL include files instead of the boost TR1 includes. Clang was > perfectly happy using its own STL include files even though they were > not part of C++98, only C++11. > > Later on, when clang 6 changed the default to gnu++14, the build > generated tons warning and some number of errors. To work around this, > I added the -std=gnu++98 compiler flag to force the old mode. > > FreeBSD on powerpc still uses gcc and it recently came to my attention > that the build was broken there. The FreeBSD port of AOO to powerpc > does not use -DHAVE_STL_INCLUDE_PATH, so it was falling back to the > boost TR1 headers. The FreeBSD port uses the system boost, and recent > versions of boost have dropped TR1 support. To work around that, I > tried enabling -DHAVE_STL_INCLUDE_PATH to use the gcc C++ headers. This > failed badly because the gcc STL headers check to see if the compilation > mode is C++11 or better and immediately error out of this is not the > case. Switching the compilation mode to c++11 results in the warning > and error spew mentioned above. I tried modifying the stlport headers > to include the gcc TR1 headers in gnu++98 mode. That worked better, but > I still got some mysterious C++ errors that I was not able to figure > out. My next attempt will be to try the boost non-TR1 headers. That was a dead end. Recent boost appears to assume that the STL headers are provided by the system. I'll probably have to switch back to bundled boost and use its TR1 headers. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
C++ standard when building OpenOffice
For much of our history, until fairly recently, the versions of gcc that we used defaulted to -std=gnu++98 when compiiling C++ code. When FreeBSD on i386 and amd64 switched from gcc to clang, it also defaulted to -std=gnu++98. Clang has been C++11 compliant from version 3.3 onwards. Around the time of the switch, I added the -DHAVE_STL_INCLUDE_PATH compiler flag so that clang would use it's own STL include files instead of the boost TR1 includes. Clang was perfectly happy using its own STL include files even though they were not part of C++98, only C++11. Later on, when clang 6 changed the default to gnu++14, the build generated tons warning and some number of errors. To work around this, I added the -std=gnu++98 compiler flag to force the old mode. FreeBSD on powerpc still uses gcc and it recently came to my attention that the build was broken there. The FreeBSD port of AOO to powerpc does not use -DHAVE_STL_INCLUDE_PATH, so it was falling back to the boost TR1 headers. The FreeBSD port uses the system boost, and recent versions of boost have dropped TR1 support. To work around that, I tried enabling -DHAVE_STL_INCLUDE_PATH to use the gcc C++ headers. This failed badly because the gcc STL headers check to see if the compilation mode is C++11 or better and immediately error out of this is not the case. Switching the compilation mode to c++11 results in the warning and error spew mentioned above. I tried modifying the stlport headers to include the gcc TR1 headers in gnu++98 mode. That worked better, but I still got some mysterious C++ errors that I was not able to figure out. My next attempt will be to try the boost non-TR1 headers. Turning to Linux as a stepping stone, I've notice the build warning spewage on recent Linux distributions, such as Debian 9, that have newer versions of gcc. By using the patch below, I was able to reduce the size of the build log for trunk from 1354815 lines to 359998 lines. I think the extra compiler defines are required because the compiler detection code in our bundled version of boost is too old to figure out what to do with new gcc in gnu++98 mode. One of the largest contributors to the warnings is std::auto_ptr. This is deprecated in C++11 and is totally removed in C++17. The new way is to use std::unique_ptr, but that wasn't available before C++11. We can't fix our code for this until we are totally off the old toolchains, which means after we have abandoned CentOS 6 and earlier as well as Visual Studio earlier than 2015. Once our code has been converted to C++11, then I think we might be able to deorbit the boost and stlport modules and just use the compiler includes directly. diff --git a/main/solenv/gbuild/platform/linux.mk b/main/solenv/gbuild/platform/linux.mk index 3f35f2a3ce..0ffaf1a84f 100644 --- a/main/solenv/gbuild/platform/linux.mk +++ b/main/solenv/gbuild/platform/linux.mk @@ -89,6 +89,10 @@ gb_CXXFLAGS := \ -fuse-cxa-atexit \ -fvisibility-inlines-hidden \ -fvisibility=hidden \ + -std=gnu++98 \ + -DBOOST_NO_CXX11_VARIADIC_TEMPLATES \ + -DBOOST_NO_CXX11_RVALUE_REFERENCES \ + -DBOOST_NO_CXX11_STATIC_ASSERT \ -pipe \ ifneq ($(EXTERNAL_WARNINGS_NOT_ERRORS),TRUE) diff --git a/main/solenv/inc/unxlng.mk b/main/solenv/inc/unxlng.mk index afaa50a0e5..060ee5976c 100644 --- a/main/solenv/inc/unxlng.mk +++ b/main/solenv/inc/unxlng.mk @@ -77,7 +77,7 @@ CFLAGSENABLESYMBOLS=-g # was temporarily commented out, reenabled before Beta .ENDIF # flags for the C++ Compiler -CFLAGSCC= -pipe $(ARCH_FLAGS) +CFLAGSCC= -pipe $(ARCH_FLAGS) -std=gnu++98 -DBOOST_NO_CXX11_VARIADIC_TEMPLATES -DBOOST_NO_CXX11_RVALUE_REFERENCES -DBOOST_NO_CXX11_STATIC_ASSERT # Flags for enabling exception handling .IF "$(COM)"=="CLANG" CFLAGSEXCEPTIONS=-fexceptions - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [openoffice] 03/03: Fixes from upstream for newer GCC
Slack is the new ASF IRC. Sorry I do not manage to make time. All time I have is eaten by reading mails. :( Am 2. November 2019 19:54:54 MEZ schrieb Matthias Seidel : >Hi Ariel, > >Am 02.11.19 um 18:57 schrieb Matthias Seidel: >> Hi Ariel, >> >> Am 02.11.19 um 18:49 schrieb Ariel Constenla-Haile: >>> On Sat, Nov 2, 2019 at 5:53 AM Peter Kovacs >wrote: On Windows the issue is that the Git() command checks out the data >at a position where cygwin does not see it. On the other hand if I pass the command directly no checkout >happens. >>> It's always useful to see the logs: >>> >https://ci.apache.org/builders/openoffice-win7/builds/37/steps/git%20clone%20under%20cygwin/logs/stdio >>> >>> + cd /home/buildslave >>> ... >>> + git clone --single-branch --branch trunk >>> https://gitbox.apache.org/repos/asf/openoffice.git build >>> fatal: destination path 'build' already exists and is not an empty >directory. >>> >>> You have to cd to the right dir, quite strange some line below you >>> seem to do so... >>> You also removed the svn revision stuff but left got_revision. >>> It looks like the underlying OS was changed from Win7 32 bits to >Win10 >>> 64 bits, that's good news, the buildbot is capable of building >>> releases. >> Yes, Windows was updated some years ago, but we didn't change the >names >> of the builbots... ;-) >>> Quite strange you changed the name (aoo - openoffice) but not the >win7 ;) >>> >>> Now the buildbot stops due to missing NASM >>> >https://ci.apache.org/builders/openoffice-win7/builds/40/steps/configure/logs/stdio >>> checking nasm.exe assembler path... checking for nasm.exe... no >>> configure: error: NASM is required to build on Windows, please >install >>> or use --with-nasm-home >>> program finished with exit code 1 >> NASM is a new requirement now. I think it was related to the updated >> OpenSSL version. >>> I don't have any machine with Windows to build, so please someone >>> building master/trunk on Windows (Matthias?) open a jira ticket >>> requesting to install NASM (once installed, the shell command should >>> include the new switch). >> I will do so! > >Done: > >https://issues.apache.org/jira/browse/INFRA-19373 > >I have also added you to our Slack channel, I hope you don't mind... >;-) > >Matthias > >> >> Regards, >> >> Matthias >> >>> Regards
