openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <>
Subject Re: C++ standard when building OpenOffice
Date Mon, 04 Nov 2019 03:31:27 GMT

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:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

This email has been checked for viruses by AVG.

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

View raw message