C++ standard when building OpenOffice

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

C++ standard when building OpenOffice

Don Lewis-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Don Lewis-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Damjan Jovanovic
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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Branko Čibej
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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Patricia Shanahan


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

--
This email has been checked for viruses by AVG.
https://www.avg.com


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Damjan Jovanovic
In reply to this post by Branko Čibej
On Mon, Nov 4, 2019 at 3:49 AM Branko Čibej <[hidden email]> 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++).
Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Branko Čibej
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Peter Kovacs-3
In reply to this post by Don Lewis-2
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 <[hidden email]>:

>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: [hidden email]
>For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Patricia Shanahan
In reply to this post by Damjan Jovanovic


On 11/3/2019 8:15 PM, Damjan Jovanovic wrote:

> On Mon, Nov 4, 2019 at 3:49 AM Branko Čibej <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Don Lewis-2
In reply to this post by Don Lewis-2
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.000000000 -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 later
  //
 -#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)
-+#if ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__GNUC__ > 6) || (__GNUC__ == 6 && __GNUC_MINOR__ > 0)
++#if ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__cplusplus >= 201103L)
  // C++0x features are only enabled when -std=c++0x or -std=gnu++0x are
  // passed on the command line, which in turn defines
  // __GXX_EXPERIMENTAL_CXX0X__.
-@@ -153,7 +153,7 @@
+ #  define BOOST_HAS_DECLTYPE
+ #  define BOOST_HAS_RVALUE_REFS
+ #  define BOOST_HAS_STATIC_ASSERT
+-#  define BOOST_HAS_VARIADIC_TMPL
++#  if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4))
++#    define BOOST_HAS_VARIADIC_TMPL
++#  else
++#    define BOOST_NO_CXX11_VARIADIC_TEMPLATES
++#  endif
+ #else
+ #  define BOOST_NO_CXX11_DECLTYPE
+ #  define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS
+@@ -153,7 +157,7 @@
 
  // Variadic templates compiler:
  //   http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html
 -#  if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__))
-+#  if defined(__VARIADIC_TEMPLATES) || ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__GNUC__ > 6) || (__GNUC__ == 6 && __GNUC_MINOR__ > 0)
++#  if defined(__VARIADIC_TEMPLATES)
  #    define BOOST_HAS_VARIADIC_TMPL
  #  else
  #    define BOOST_NO_CXX11_VARIADIC_TEMPLATES
diff --git a/main/solenv/gbuild/platform/linux.mk b/main/solenv/gbuild/platform/linux.mk
index 3f35f2a3ce..02b8830a39 100644
--- a/main/solenv/gbuild/platform/linux.mk
+++ b/main/solenv/gbuild/platform/linux.mk
@@ -89,6 +89,7 @@ gb_CXXFLAGS := \
  -fuse-cxa-atexit \
  -fvisibility-inlines-hidden \
  -fvisibility=hidden \
+ -std=gnu++98 \
  -pipe \
 
 ifneq ($(EXTERNAL_WARNINGS_NOT_ERRORS),TRUE)
diff --git a/main/solenv/inc/unxlng.mk b/main/solenv/inc/unxlng.mk
index afaa50a0e5..32b88bc91d 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
 # Flags for enabling exception handling
 .IF "$(COM)"=="CLANG"
 CFLAGSEXCEPTIONS=-fexceptions
 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Peter Kovacs-3
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 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.000000000 -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 later
>   //
>  -#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)
> -+#if ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__GNUC__ > 6) || (__GNUC__ == 6 && __GNUC_MINOR__ > 0)
> ++#if ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__cplusplus >= 201103L)
>   // C++0x features are only enabled when -std=c++0x or -std=gnu++0x are
>   // passed on the command line, which in turn defines
>   // __GXX_EXPERIMENTAL_CXX0X__.
> -@@ -153,7 +153,7 @@
> + #  define BOOST_HAS_DECLTYPE
> + #  define BOOST_HAS_RVALUE_REFS
> + #  define BOOST_HAS_STATIC_ASSERT
> +-#  define BOOST_HAS_VARIADIC_TMPL
> ++#  if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4))
> ++#    define BOOST_HAS_VARIADIC_TMPL
> ++#  else
> ++#    define BOOST_NO_CXX11_VARIADIC_TEMPLATES
> ++#  endif
> + #else
> + #  define BOOST_NO_CXX11_DECLTYPE
> + #  define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS
> +@@ -153,7 +157,7 @@
>  
>   // Variadic templates compiler:
>   //   http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html
>  -#  if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__))
> -+#  if defined(__VARIADIC_TEMPLATES) || ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__GNUC__ > 6) || (__GNUC__ == 6 && __GNUC_MINOR__ > 0)
> ++#  if defined(__VARIADIC_TEMPLATES)
>   #    define BOOST_HAS_VARIADIC_TMPL
>   #  else
>   #    define BOOST_NO_CXX11_VARIADIC_TEMPLATES
> diff --git a/main/solenv/gbuild/platform/linux.mk b/main/solenv/gbuild/platform/linux.mk
> index 3f35f2a3ce..02b8830a39 100644
> --- a/main/solenv/gbuild/platform/linux.mk
> +++ b/main/solenv/gbuild/platform/linux.mk
> @@ -89,6 +89,7 @@ gb_CXXFLAGS := \
>   -fuse-cxa-atexit \
>   -fvisibility-inlines-hidden \
>   -fvisibility=hidden \
> + -std=gnu++98 \
>   -pipe \
>  
>  ifneq ($(EXTERNAL_WARNINGS_NOT_ERRORS),TRUE)
> diff --git a/main/solenv/inc/unxlng.mk b/main/solenv/inc/unxlng.mk
> index afaa50a0e5..32b88bc91d 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
>  # Flags for enabling exception handling
>  .IF "$(COM)"=="CLANG"
>  CFLAGSEXCEPTIONS=-fexceptions
>  
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Mechtilde Stehmann-2
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Peter Kovacs-4
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 <[hidden email]>:

>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.
Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Jim Jagielski
In reply to this post by Peter Kovacs-3
FWIW, macOS is clang, llvm, etc... it only pretends to be gcc :)

> On Nov 5, 2019, at 1:44 AM, Peter Kovacs <[hidden email]> 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 "$(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.000000000 -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 later
>>  //
>> -#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)
>> -+#if ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__GNUC__ > 6) || (__GNUC__ == 6 && __GNUC_MINOR__ > 0)
>> ++#if ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__cplusplus >= 201103L)
>>  // C++0x features are only enabled when -std=c++0x or -std=gnu++0x are
>>  // passed on the command line, which in turn defines
>>  // __GXX_EXPERIMENTAL_CXX0X__.
>> -@@ -153,7 +153,7 @@
>> + #  define BOOST_HAS_DECLTYPE
>> + #  define BOOST_HAS_RVALUE_REFS
>> + #  define BOOST_HAS_STATIC_ASSERT
>> +-#  define BOOST_HAS_VARIADIC_TMPL
>> ++#  if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4))
>> ++#    define BOOST_HAS_VARIADIC_TMPL
>> ++#  else
>> ++#    define BOOST_NO_CXX11_VARIADIC_TEMPLATES
>> ++#  endif
>> + #else
>> + #  define BOOST_NO_CXX11_DECLTYPE
>> + #  define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS
>> +@@ -153,7 +157,7 @@
>>
>>  // Variadic templates compiler:
>>  //   http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html
>> -#  if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__))
>> -+#  if defined(__VARIADIC_TEMPLATES) || ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__GNUC__ > 6) || (__GNUC__ == 6 && __GNUC_MINOR__ > 0)
>> ++#  if defined(__VARIADIC_TEMPLATES)
>>  #    define BOOST_HAS_VARIADIC_TMPL
>>  #  else
>>  #    define BOOST_NO_CXX11_VARIADIC_TEMPLATES
>> diff --git a/main/solenv/gbuild/platform/linux.mk b/main/solenv/gbuild/platform/linux.mk
>> index 3f35f2a3ce..02b8830a39 100644
>> --- a/main/solenv/gbuild/platform/linux.mk
>> +++ b/main/solenv/gbuild/platform/linux.mk
>> @@ -89,6 +89,7 @@ gb_CXXFLAGS := \
>> -fuse-cxa-atexit \
>> -fvisibility-inlines-hidden \
>> -fvisibility=hidden \
>> + -std=gnu++98 \
>> -pipe \
>>
>> ifneq ($(EXTERNAL_WARNINGS_NOT_ERRORS),TRUE)
>> diff --git a/main/solenv/inc/unxlng.mk b/main/solenv/inc/unxlng.mk
>> index afaa50a0e5..32b88bc91d 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
>> # Flags for enabling exception handling
>> .IF "$(COM)"=="CLANG"
>> CFLAGSEXCEPTIONS=-fexceptions
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Don Lewis-2
In reply to this post by Peter Kovacs-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Matthias Seidel
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Don Lewis-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Don Lewis-2
In reply to this post by Don Lewis-2
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.000000000 -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 later
>   //
>  -#if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)
> -+#if ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__GNUC__ > 6) || (__GNUC__ == 6 && __GNUC_MINOR__ > 0)
> ++#if ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__cplusplus >= 201103L)
>   // C++0x features are only enabled when -std=c++0x or -std=gnu++0x are
>   // passed on the command line, which in turn defines
>   // __GXX_EXPERIMENTAL_CXX0X__.
> -@@ -153,7 +153,7 @@
> + #  define BOOST_HAS_DECLTYPE
> + #  define BOOST_HAS_RVALUE_REFS
> + #  define BOOST_HAS_STATIC_ASSERT
> +-#  define BOOST_HAS_VARIADIC_TMPL
> ++#  if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4))
> ++#    define BOOST_HAS_VARIADIC_TMPL
> ++#  else
> ++#    define BOOST_NO_CXX11_VARIADIC_TEMPLATES
> ++#  endif
> + #else
> + #  define BOOST_NO_CXX11_DECLTYPE
> + #  define BOOST_NO_CXX11_FUNCTION_TEMPLATE_DEFAULT_ARGS
> +@@ -153,7 +157,7 @@
>  
>   // Variadic templates compiler:
>   //   http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html
>  -#  if defined(__VARIADIC_TEMPLATES) || (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4) && defined(__GXX_EXPERIMENTAL_CXX0X__))
> -+#  if defined(__VARIADIC_TEMPLATES) || ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__)) || (__GNUC__ > 6) || (__GNUC__ == 6 && __GNUC_MINOR__ > 0)
> ++#  if defined(__VARIADIC_TEMPLATES)
>   #    define BOOST_HAS_VARIADIC_TMPL
>   #  else
>   #    define BOOST_NO_CXX11_VARIADIC_TEMPLATES
> diff --git a/main/solenv/gbuild/platform/linux.mk b/main/solenv/gbuild/platform/linux.mk
> index 3f35f2a3ce..02b8830a39 100644
> --- a/main/solenv/gbuild/platform/linux.mk
> +++ b/main/solenv/gbuild/platform/linux.mk
> @@ -89,6 +89,7 @@ gb_CXXFLAGS := \
>   -fuse-cxa-atexit \
>   -fvisibility-inlines-hidden \
>   -fvisibility=hidden \
> + -std=gnu++98 \
>   -pipe \
>  
>  ifneq ($(EXTERNAL_WARNINGS_NOT_ERRORS),TRUE)
> diff --git a/main/solenv/inc/unxlng.mk b/main/solenv/inc/unxlng.mk
> index afaa50a0e5..32b88bc91d 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
>  # Flags for enabling exception handling
>  .IF "$(COM)"=="CLANG"
>  CFLAGSEXCEPTIONS=-fexceptions

Now that I have committed the boost fixes, the patch below is all that
is needed to build in gnu++98 mode.  My previous patch to the .mk files
was slightly incorrect.  I was mislead by the comments and added
std=gnu++98 to the wrong line.  This further greatly reduces the size of
build log:
        c++11 mode:              1354815 lines
        gnu++98 mode (previous):  360051 lines
        gnu++98 mode (latest):    246152 lines

diff --git a/main/solenv/gbuild/platform/linux.mk b/main/solenv/gbuild/platform/linux.mk
index 3f35f2a3ce..02b8830a39 100644
--- a/main/solenv/gbuild/platform/linux.mk
+++ b/main/solenv/gbuild/platform/linux.mk
@@ -89,6 +89,7 @@ gb_CXXFLAGS := \
  -fuse-cxa-atexit \
  -fvisibility-inlines-hidden \
  -fvisibility=hidden \
+ -std=gnu++98 \
  -pipe \
 
 ifneq ($(EXTERNAL_WARNINGS_NOT_ERRORS),TRUE)
diff --git a/main/solenv/inc/unxlng.mk b/main/solenv/inc/unxlng.mk
index afaa50a0e5..f79f3b15aa 100644
--- a/main/solenv/inc/unxlng.mk
+++ b/main/solenv/inc/unxlng.mk
@@ -88,7 +88,7 @@ CFLAGSEXCEPTIONS=-fexceptions -fno-enforce-eh-specs
 CFLAGS_NO_EXCEPTIONS=-fno-exceptions
 
 # -fpermissive should be removed as soon as possible
-CFLAGSCXX= -pipe $(ARCH_FLAGS)
+CFLAGSCXX= -pipe $(ARCH_FLAGS) -std=gnu++98
 .IF "$(HAVE_GCC_VISIBILITY_FEATURE)" == "TRUE"
 CFLAGSCXX += -fvisibility-inlines-hidden
 .ENDIF # "$(HAVE_GCC_VISIBILITY_FEATURE)" == "TRUE"


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Jim Jagielski
In reply to this post by Don Lewis-2


> On Nov 5, 2019, at 1:56 PM, Don Lewis <[hidden email]> 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.
Reply | Threaded
Open this post in threaded view
|

Re: C++ standard when building OpenOffice

Jim Jagielski
In reply to this post by Don Lewis-2
I am curious what system you build and test these patches on before you commit... Thx!
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12