Re: C++ standard when building OpenOffice
Hi Peter, > I could not figure out if OS/2 can use LLVM. @Yuri do you think that > would be fine for the OS/2 development? OS/2 currently does not support LLVM building. I know a LLVM part was available (maybe a library) but for sure the whole building env isn't. thanks Yuri - 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 Tue, Nov 5, 2019 at 10:05 PM Don Lewis wrote: > > I thought that Damjan implemenented that. > > I have a patch that does gstreamer-1.0 access through run-time dynamic linking, so we should in theory just need the gstreamer source for its header files at compile time. It hasn't been tested or committed, and it's pretty ugly code: gstreamer really wasn't designed to be used through run-time dynamic linking.
Re: C++ standard when building OpenOffice
On 5 Nov, Pedro Giffuni wrote: > Hi; > > Some notes, which I don't expect will be particularly useful ... > > - I recall one of the reasons for using Boost and not the native STL was > that the old MSVC compiler (the one AOO still uses) is poor on standards > compliance. It may be that the internal Boost can be updated a bit more > but it has to be tested on the Windows build. I didn't look closely at all the stlport headers, but at least some of them forward to Microsoft's include files. The main user of boost is gcc, which uses the boost TR1 headers, previously in all cases, and more recently just in C++98 mode. The only wrinkles have been the removal of the TR1 headers in the more modern version of boost installed by the FreeBSD port, and the broken logic for the compiler feature flags in the old bundled boost. > - Microsoft's STL implementation is now open source and clang is supported: > > https://github.com/microsoft/STL > > - While FreeBSD PowerPC is a moving target, the destination is clang, > spending time on the GCC build there is probably a waste of time: > > https://wiki.freebsd.org/powerpc/llvm-elfv2 The clang build also fails. Right now it fails in configure for some reason, but even once we get past that, the result of the build will likely be broken if the system libraries are built with g++. That probably means that building with clang will be limited to FreeBSD 13. I do have a version of the 4.1.7 port that looks like it should work on FreeBSD/powerpc with gcc. It gets most of the way through the build on amd64, but fails at the end because unopkg core dumps when building instsetoo_native. I suspect the problem is mixing clang++ and g++ compiled code (the reverse case of using clang on powerpc). I'm waiting to hear if it actually works before I commit the port update. Once clang is native on powerpc, I think the existing port should just work, or be very close. > - Rust is really interesting :). > > Pedro. > > > > - > 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
Hi; Some notes, which I don't expect will be particularly useful ... - I recall one of the reasons for using Boost and not the native STL was that the old MSVC compiler (the one AOO still uses) is poor on standards compliance. It may be that the internal Boost can be updated a bit more but it has to be tested on the Windows build. - Microsoft's STL implementation is now open source and clang is supported: https://github.com/microsoft/STL - While FreeBSD PowerPC is a moving target, the destination is clang, spending time on the GCC build there is probably a waste of time: https://wiki.freebsd.org/powerpc/llvm-elfv2 - Rust is really interesting :). Pedro. - 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 5 Nov, Jim Jagielski wrote: > > >> On Nov 5, 2019, at 1:56 PM, Don Lewis wrote: >> >> On 5 Nov, Matthias Seidel wrote: 4.1.x. >>> >>> To my knowledge we build 4.2.x on CentOS 7. > > Yep. > >> >> It builds and works fine on CentOS 6 as well. > > The issue is gstreamer1, as well as other dependencies... as noted at > https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step and earlier in this thread. > > That's why we've switched to CentOS7 as our canon build server for AOO > 4.2.x and later (we could also switch to Ubuntu 14.04 but it was > deemed prudent to stay w/ RHEL-like). Even so, we can build on CentOS7 > and still run on CentOS6. Does that work with the older libraries like libstdc++ on CentOS6. The libraries are versioned, so the APIs used by something built on CentOS 6 are present in the CentOS 7 library, but the reverse is not true. >> >>> 4.1.x is still built on CentOS 5. >> > > Yep. > > The question isn't so much what versions we support but rather what we > use/specify as our canon builds. Could we create our community builds > on a CentOS6 server? Sure, but we'd need to disable gstreamer totally. > There was some discussion about making it a runtime dependency instead > of a build one, but afaik no work has been done in that regards. I thought that Damjan implemenented that. - 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 5 Nov, Jim Jagielski wrote: > I am curious what system you build and test these patches on before > you commit... Thx! CentOS 6, Debian 9, FreeBSD 11, and Windows 7. Sometimes CentOS 7, Ubuntu 16 and FreeBSD as well. A mix of 32 and 64 bit. - 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
I am curious what system you build and test these patches on before you commit... Thx! - 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 Nov 5, 2019, at 1:56 PM, Don Lewis wrote: > > On 5 Nov, Matthias Seidel wrote: >>> >>> 4.1.x. >> >> To my knowledge we build 4.2.x on CentOS 7. Yep. > > It builds and works fine on CentOS 6 as well. The issue is gstreamer1, as well as other dependencies... as noted at https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step and earlier in this thread. That's why we've switched to CentOS7 as our canon build server for AOO 4.2.x and later (we could also switch to Ubuntu 14.04 but it was deemed prudent to stay w/ RHEL-like). Even so, we can build on CentOS7 and still run on CentOS6. > >> 4.1.x is still built on CentOS 5. > Yep. The question isn't so much what versions we support but rather what we use/specify as our canon builds. Could we create our community builds on a CentOS6 server? Sure, but we'd need to disable gstreamer totally. There was some discussion about making it a runtime dependency instead of a build one, but afaik no work has been done in that regards.
Re: C++ standard when building OpenOffice
On 4 Nov, 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. >> >> 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 > > If I fix the compiler feature detection code in boost, then the changes > needed to always build in gnu++98 mode on Linux are pretty trivial: > > diff --git a/main/boost/boost_1_55_0.patch b/main/boost/boost_1_55_0.patch > index 6cec7bb358..df9b8ec8e0 100644 > --- a/main/boost/boost_1_55_0.patch > +++ b/main/boost/boost_1_55_0.patch > @@ -328,22 +328,34 @@ diff -ur > misc/boost_1_55_0/boost/unordered/detail/unique.hpp misc/build/boost_1_ > > > diff -ur misc/boost_1_55_0/boost/config/compiler/gcc.hpp > misc/build/boost_1_55_0/boost/config/compiler/gcc.hpp > --- misc/boost_1_55_0/boost/config/compiler/gcc.hpp 2013-09-17 > 09:55:51.0 -0700 > -+++ misc/build/boost_1_55_0/boost/config/compiler/gcc.hpp2016-09-02 > 19:15:48.775411000 -0700 > -@@ -137,7 +137,7 @@ >
Re: C++ standard when building OpenOffice
On 5 Nov, Matthias Seidel wrote: > Hi Don, > > Am 05.11.19 um 19:02 schrieb Don Lewis: >> On 5 Nov, Peter Kovacs wrote: >>> what if we require LLVM as build requirement and build OpenOffice only >>> with LLVM instead of preinstalled gcc? >>> >>> the project provides packages for Windows, Linux (And here RHEL 7.4) and >>> mac. Cygwin offers Version 8.01 >>> >>> Debian offers also LLVM as Version 8. >>> >>> It would just work around the issue we currently face, while increasing >>> the build requirements only by little. >> That's not likely to be helpful. Mixing an application built with LLVM >> with system C++ libraries compiled with gcc is likely to fail. It is >> best to use the same compiler for everything. Also, using a non-default >> compiler would require the user to install the matching C++ runtime >> libraries. >> >> What set me on this quest was trying to build 4.1.7 with gcc on >> FreeBSD/powerpc, where LLVM is not quite ready for prime time. >> >> Either compiler can generally be persuaded to work. In C++98 mode, LLVM >> can use it's regular C++ STL headers, whereas GCC needs to use the boost >> TR1 headers for STL. In C++11 mode, either compiler can use the C++ STL >> headers, but our code isn't quite ready for C++11, and we can't yet make >> the changes for C++11 that are not compatible with the older compilers >> on some platforms. >> >>> We have to drop CentOS6 support completely, as a price, but I think this >>> is already decided. >> Dropping support for CentOS 6 for 4.2.x would be nice for a couple of >> reasons. GCC on CentOS 6 doesn't support C++11, and CentOS 6 is our >> last platform that doesn't have the new gstreamer. But if we don't >> support CentOS 6 for 4.2.x, then we probably need to extend support for >> 4.1.x. > > To my knowledge we build 4.2.x on CentOS 7. It builds and works fine on CentOS 6 as well. > 4.1.x is still built on CentOS 5. Unfortunately my CentOS 5 VM is trashed and because CentOS 5 is past EOL< it is a PITA to fix. - 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
Hi Don, Am 05.11.19 um 19:02 schrieb Don Lewis: > On 5 Nov, Peter Kovacs wrote: >> what if we require LLVM as build requirement and build OpenOffice only >> with LLVM instead of preinstalled gcc? >> >> the project provides packages for Windows, Linux (And here RHEL 7.4) and >> mac. Cygwin offers Version 8.01 >> >> Debian offers also LLVM as Version 8. >> >> It would just work around the issue we currently face, while increasing >> the build requirements only by little. > That's not likely to be helpful. Mixing an application built with LLVM > with system C++ libraries compiled with gcc is likely to fail. It is > best to use the same compiler for everything. Also, using a non-default > compiler would require the user to install the matching C++ runtime > libraries. > > What set me on this quest was trying to build 4.1.7 with gcc on > FreeBSD/powerpc, where LLVM is not quite ready for prime time. > > Either compiler can generally be persuaded to work. In C++98 mode, LLVM > can use it's regular C++ STL headers, whereas GCC needs to use the boost > TR1 headers for STL. In C++11 mode, either compiler can use the C++ STL > headers, but our code isn't quite ready for C++11, and we can't yet make > the changes for C++11 that are not compatible with the older compilers > on some platforms. > >> We have to drop CentOS6 support completely, as a price, but I think this >> is already decided. > Dropping support for CentOS 6 for 4.2.x would be nice for a couple of > reasons. GCC on CentOS 6 doesn't support C++11, and CentOS 6 is our > last platform that doesn't have the new gstreamer. But if we don't > support CentOS 6 for 4.2.x, then we probably need to extend support for > 4.1.x. To my knowledge we build 4.2.x on CentOS 7. 4.1.x is still built on CentOS 5. Regards, Matthias >> I could not figure out if OS/2 can use LLVM. @Yuri do you think that >> would be fine for the OS/2 development? >> >> It would simplify things a lot, and we can jump up the standard requirement. > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > smime.p7s Description: S/MIME Cryptographic Signature
Re: C++ standard when building OpenOffice
On 5 Nov, Peter Kovacs wrote: > what if we require LLVM as build requirement and build OpenOffice only > with LLVM instead of preinstalled gcc? > > the project provides packages for Windows, Linux (And here RHEL 7.4) and > mac. Cygwin offers Version 8.01 > > Debian offers also LLVM as Version 8. > > It would just work around the issue we currently face, while increasing > the build requirements only by little. That's not likely to be helpful. Mixing an application built with LLVM with system C++ libraries compiled with gcc is likely to fail. It is best to use the same compiler for everything. Also, using a non-default compiler would require the user to install the matching C++ runtime libraries. What set me on this quest was trying to build 4.1.7 with gcc on FreeBSD/powerpc, where LLVM is not quite ready for prime time. Either compiler can generally be persuaded to work. In C++98 mode, LLVM can use it's regular C++ STL headers, whereas GCC needs to use the boost TR1 headers for STL. In C++11 mode, either compiler can use the C++ STL headers, but our code isn't quite ready for C++11, and we can't yet make the changes for C++11 that are not compatible with the older compilers on some platforms. > We have to drop CentOS6 support completely, as a price, but I think this > is already decided. Dropping support for CentOS 6 for 4.2.x would be nice for a couple of reasons. GCC on CentOS 6 doesn't support C++11, and CentOS 6 is our last platform that doesn't have the new gstreamer. But if we don't support CentOS 6 for 4.2.x, then we probably need to extend support for 4.1.x. > I could not figure out if OS/2 can use LLVM. @Yuri do you think that > would be fine for the OS/2 development? > > It would simplify things a lot, and we can jump up the standard requirement. - 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
FWIW, macOS is clang, llvm, etc... it only pretends to be gcc :) > On Nov 5, 2019, at 1:44 AM, Peter Kovacs wrote: > > what if we require LLVM as build requirement and build OpenOffice only > with LLVM instead of preinstalled gcc? > > the project provides packages for Windows, Linux (And here RHEL 7.4) and > mac. Cygwin offers Version 8.01 > > Debian offers also LLVM as Version 8. > > It would just work around the issue we currently face, while increasing > the build requirements only by little. > > We have to drop CentOS6 support completely, as a price, but I think this > is already decided. > > I could not figure out if OS/2 can use LLVM. @Yuri do you think that > would be fine for the OS/2 development? > > It would simplify things a lot, and we can jump up the standard requirement. > > > Maybe I miss some cave eats. Sorry for this. > > On 05.11.19 02:19, 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. >>> >>> 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
Re: C++ standard when building OpenOffice
It seems llvm provides 8.0 llvm builds: https://apt.llvm.org/ I am irritated they say it is nightly. But I am unsure what version 8 might have. Am 5. November 2019 10:19:56 MEZ schrieb Mechtilde : >Hello, > >Am 05.11.19 um 07:44 schrieb Peter Kovacs: >> what if we require LLVM as build requirement and build OpenOffice >only >> with LLVM instead of preinstalled gcc? >> >> the project provides packages for Windows, Linux (And here RHEL 7.4) >and >> mac. Cygwin offers Version 8.01 >> >> Debian offers also LLVM as Version 8. > >Dies is only for the upcoming Debian version 11. In Debian 9 which I >used to build is LLVM version 3.8, and in the recent Debian 10 is >version 7.0. > >And at this time I can't build bith Debian 10 esp. because of Java 11. > >Kind regards >-- >Mechtilde Stehmann >## Apache OpenOffice >## Freie Office Suite für Linux, MacOSX, Windows >## Debian Developer >## PGP encryption welcome >## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Re: C++ standard when building OpenOffice
Hello, Am 05.11.19 um 07:44 schrieb Peter Kovacs: > what if we require LLVM as build requirement and build OpenOffice only > with LLVM instead of preinstalled gcc? > > the project provides packages for Windows, Linux (And here RHEL 7.4) and > mac. Cygwin offers Version 8.01 > > Debian offers also LLVM as Version 8. Dies is only for the upcoming Debian version 11. In Debian 9 which I used to build is LLVM version 3.8, and in the recent Debian 10 is version 7.0. And at this time I can't build bith Debian 10 esp. because of Java 11. Kind regards -- Mechtilde Stehmann ## Apache OpenOffice ## Freie Office Suite für Linux, MacOSX, Windows ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
Re: C++ standard when building OpenOffice
what if we require LLVM as build requirement and build OpenOffice only with LLVM instead of preinstalled gcc? the project provides packages for Windows, Linux (And here RHEL 7.4) and mac. Cygwin offers Version 8.01 Debian offers also LLVM as Version 8. It would just work around the issue we currently face, while increasing the build requirements only by little. We have to drop CentOS6 support completely, as a price, but I think this is already decided. I could not figure out if OS/2 can use LLVM. @Yuri do you think that would be fine for the OS/2 development? It would simplify things a lot, and we can jump up the standard requirement. Maybe I miss some cave eats. Sorry for this. On 05.11.19 02:19, 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. >> >> 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 > If I fix the compiler feature detection code in boost, then the changes > needed to always build in gnu++98 mode on Linux are pretty trivial: > > diff --git a/main/boost/boost_1_55_0.patch
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. > > 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 If I fix the compiler feature detection code in boost, then the changes needed to always build in gnu++98 mode on Linux are pretty trivial: diff --git a/main/boost/boost_1_55_0.patch b/main/boost/boost_1_55_0.patch index 6cec7bb358..df9b8ec8e0 100644 --- a/main/boost/boost_1_55_0.patch +++ b/main/boost/boost_1_55_0.patch @@ -328,22 +328,34 @@ diff -ur misc/boost_1_55_0/boost/unordered/detail/unique.hpp misc/build/boost_1_ diff -ur misc/boost_1_55_0/boost/config/compiler/gcc.hpp misc/build/boost_1_55_0/boost/config/compiler/gcc.hpp --- misc/boost_1_55_0/boost/config/compiler/gcc.hpp2013-09-17 09:55:51.0 -0700 -+++ misc/build/boost_1_55_0/boost/config/compiler/gcc.hpp 2016-09-02 19:15:48.775411000 -0700 -@@ -137,7 +137,7 @@ misc/build/boost_1_55_0/boost/config/compiler/gcc.hpp 2019-11-04 09:59:20.741944674 -0800 +@@ -137,14 +137,18 @@ // C++0x features in 4.3.n and
Re: C++ standard when building OpenOffice
On 11/3/2019 8:15 PM, Damjan Jovanovic wrote: 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. That can be considered on its own merits for any new feature. It is not a solution to the build problem, because we will still have millions of lines of C++ that has to be built for each target. If anything, it will make the build problem worse, by adding another language to the mix. -- 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
Isn't it possible to say in stlport to define a ooo_ptr which points to auto_ptr for old and unique_ptr for the new tool chains? I think of use or type. Imho we should decouple from stdlib as much as possible to simplify maintenance. Am 3. November 2019 22:59:49 MEZ schrieb Don Lewis : >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: 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: 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
