openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <>
Subject Re: C++ standard when building OpenOffice
Date Mon, 04 Nov 2019 01:49:35 GMT
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:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message