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 <truck...@apache.org> 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
