Some baseline thoughts

classic Classic list List threaded Threaded
18 messages Options
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Some baseline thoughts

Some of our baselines on current master (towards LO 5.4) are as follows:


*  GCC 4.7
(<https://cgit.freedesktop.org/libreoffice/core/commit/?id=e4b24c7399352642aeaeb412394d6230562d04d2>
"configure: GCC 4.6 is no longer supported on master")

The latest version is GCC 6.  Noteworthy C++ conformance we would gain
with a bump (according to
<http://en.cppreference.com/w/cpp/compiler_support>) would be:

** GCC 4.8.1:
*** inheriting constructors
*** ref-qualifiers

** GCC 4.9:
*** decltype(auto), return type deduction for normal functions
*** generic lambdas
*** deprecated attribute
*** single quote as digit separator

** GCC 5:
*** variable templates
*** user-defined literals for <chrono> and <string>

The question is what old versions of GCC are required exactly by the
various builds.


*  MSVC 2015 Update 3
(<https://cgit.freedesktop.org/libreoffice/core/commit/?id=84b36c704d73362d4d86dc9e9c0efa0625958347>
"Drop support for MSVC 2013")

Bumping this to MSVC 2017 is unlikely to happen anytime soon, given we
bumped to MSVC 2015 Update 3 only recently.


*  For --enable-compiler-plugins, Clang 3.4
(<https://cgit.freedesktop.org/libreoffice/core/commit/?id=733198de1b7fc3907609217147704f493f6146e6>
"Remove support for Clang < 3.4")

The latest version is Clang 4 (just released the other day).  Bumping
this would allow to clean up some #ifdefs across compilerplugins/clang/.
  The question is what old versions of Clang are required exactly by
people building with --enable-compiler-plugins.

(For our C++ conformance, the oldest supported Clang version is rarely
the limiting factor.)


*  macOS 10.8
(<https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/4.4&oldid=99539#Mac_OS_X>)

Bumping this to macOS 10.9 would get rid of the last known case of
!HAVE_THREADSAFE_STATICS (cf.
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=aa2fbfc4faa24cf7ee5aa9afdafddbd536ac4fec>
"Found out that Mac OS X 10.9 has working threadsafe statics").  What is
unknown however is the status on Android and iOS.  Having
HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see
e.g. <https://gerrit.libreoffice.org/#/c/35258/> "replace
double-checked-locking with C++11 static initializer".
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Miklos Vajna-4 Miklos Vajna-4
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

Hi,

On Thu, Mar 16, 2017 at 12:20:54PM +0100, Stephan Bergmann <[hidden email]> wrote:
> *  GCC 4.7 (<https://cgit.freedesktop.org/libreoffice/core/commit/?id=e4b24c7399352642aeaeb412394d6230562d04d2>
> "configure: GCC 4.6 is no longer supported on master")

openSUSE stable/SLE still defaults to gcc-4.8 (4.8.5), so depending on
4.9 or newer is a bit uncomfortable for those users (including me).

> Bumping this to macOS 10.9 would get rid of the last known case of
> !HAVE_THREADSAFE_STATICS (cf. <https://cgit.freedesktop.org/libreoffice/core/commit/?id=aa2fbfc4faa24cf7ee5aa9afdafddbd536ac4fec>
> "Found out that Mac OS X 10.9 has working threadsafe statics").  What is
> unknown however is the status on Android and iOS.  Having
> HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see e.g.
> <https://gerrit.libreoffice.org/#/c/35258/> "replace double-checked-locking
> with C++11 static initializer".

master-android$ grep -R THREADSAFE config_*/*.h
config_build/config_global.h:#define HAVE_THREADSAFE_STATICS 1
config_host/config_global.h:#define HAVE_THREADSAFE_STATICS 0

But this is not set in stone, quite possibly the Android toolchain (NDK,
which provides the C++ cross-compiler) can be updated to a newer
version, and then the problem will go away. (See
"with_android_ndk_toolchain_version=4.9" in configure.ac.)

Regards,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (188 bytes) Download Attachment
Jan-Marek Glogowski Jan-Marek Glogowski
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

In reply to this post by sberg
Am 16.03.2017 um 12:20 schrieb Stephan Bergmann:

> Some of our baselines on current master (towards LO 5.4) are as follows:
>
>
> *  GCC 4.7
> (<https://cgit.freedesktop.org/libreoffice/core/commit/?id=e4b24c7399352642aeaeb412394d6230562d04d2>
> "configure: GCC 4.6 is no longer supported on master")
>
> The latest version is GCC 6.  Noteworthy C++ conformance we would gain
> with a bump (according to
> <http://en.cppreference.com/w/cpp/compiler_support>) would be:
>
> ** GCC 4.8.1:
> *** inheriting constructors
> *** ref-qualifiers

> ** GCC 4.9:
> *** decltype(auto), return type deduction for normal functions
> *** generic lambdas
> *** deprecated attribute
> *** single quote as digit separator
>
> ** GCC 5:
> *** variable templates
> *** user-defined literals for <chrono> and <string>
>
> The question is what old versions of GCC are required exactly by the
> various builds.

Ubuntu LTS 14.04 has 4.8 as the default compiler. An update for 4.9 is
the maximum available compiler.

> *  MSVC 2015 Update 3
> (<https://cgit.freedesktop.org/libreoffice/core/commit/?id=84b36c704d73362d4d86dc9e9c0efa0625958347>
> "Drop support for MSVC 2013")
>
> Bumping this to MSVC 2017 is unlikely to happen anytime soon, given we
> bumped to MSVC 2015 Update 3 only recently.

Someone / the wiki claimed 2017 is already working, which is a
difference to the previous 2015 bump, which apparently took some time to
fix the fallout of the update.

> *  For --enable-compiler-plugins, Clang 3.4
> (<https://cgit.freedesktop.org/libreoffice/core/commit/?id=733198de1b7fc3907609217147704f493f6146e6>
> "Remove support for Clang < 3.4")
>
> The latest version is Clang 4 (just released the other day).  Bumping
> this would allow to clean up some #ifdefs across compilerplugins/clang/.
>  The question is what old versions of Clang are required exactly by
> people building with --enable-compiler-plugins.
>
> (For our C++ conformance, the oldest supported Clang version is rarely
> the limiting factor.)

Ubuntu doesn't have any official clang compiler, but provides a
clang-3.8 in the 14.04 repo, which I use for cross-checking.

I would just like to keep the 14.04 baseline because it makes backports
easier. We'll hopefully stay with 5.2 for a while, but I also thought so
about a 5.0 release, which was dropped.

JMG

P.S. 16.04 has gcc 5.3 as default and 5.4 as an update, clang still 3.8.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Christian Lohmaier-3 Christian Lohmaier-3
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

In reply to this post by sberg
Hi *,

On Thu, Mar 16, 2017 at 12:20 PM, Stephan Bergmann <[hidden email]> wrote:
> Some of our baselines on current master (towards LO 5.4) are as follows:
> […]
> ** GCC 4.8.1:
> *** inheriting constructors
> *** ref-qualifiers

FYI: baseline CentOS with devtoolset has 4.8.2

> […]
> The question is what old versions of GCC are required exactly by the various
> builds.
> […]
> *  For --enable-compiler-plugins, Clang 3.4
> (<https://cgit.freedesktop.org/libreoffice/core/commit/?id=733198de1b7fc3907609217147704f493f6146e6>
> "Remove support for Clang < 3.4")

FYI: clang for CentOS baseline from epel repo would be at 3.4.2

> […] unknown however is the status on Android and iOS.

switching to clang for android would use the llvm version, so I guess
should also be fine then. (right now it still users gcc, but support
for that is being faded out by google)

ciao
Christian
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Miklos Vajna-4 Miklos Vajna-4
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

In reply to this post by sberg
Hi,

On Thu, Mar 16, 2017 at 12:20:54PM +0100, Stephan Bergmann <[hidden email]> wrote:
> *  macOS 10.8 (<https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/4.4&oldid=99539#Mac_OS_X>)
>
> Bumping this to macOS 10.9 would get rid of the last known case of
> !HAVE_THREADSAFE_STATICS (cf. <https://cgit.freedesktop.org/libreoffice/core/commit/?id=aa2fbfc4faa24cf7ee5aa9afdafddbd536ac4fec>
> "Found out that Mac OS X 10.9 has working threadsafe statics").  What is
> unknown however is the status on Android and iOS.  Having
> HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see e.g.
> <https://gerrit.libreoffice.org/#/c/35258/> "replace double-checked-locking
> with C++11 static initializer".

Do we have any tinderbox building against the 10.8 SDK? I just realized
that the xmlsec we bundle on master now requires libxml 2.8, and as far
as I see Jenkins builds against the 10.9 SDK. So there is a risk that
the 10.8 SDK provides an older libxml and this went unnoticed.

Regards,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (188 bytes) Download Attachment
Norbert Thiebaud Norbert Thiebaud
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

On Wed, May 17, 2017 at 2:50 AM, Miklos Vajna <[hidden email]> wrote:

> Hi,
>
> On Thu, Mar 16, 2017 at 12:20:54PM +0100, Stephan Bergmann <[hidden email]> wrote:
>> *  macOS 10.8 (<https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/4.4&oldid=99539#Mac_OS_X>)
>>
>> Bumping this to macOS 10.9 would get rid of the last known case of
>> !HAVE_THREADSAFE_STATICS (cf. <https://cgit.freedesktop.org/libreoffice/core/commit/?id=aa2fbfc4faa24cf7ee5aa9afdafddbd536ac4fec>
>> "Found out that Mac OS X 10.9 has working threadsafe statics").  What is
>> unknown however is the status on Android and iOS.  Having
>> HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see e.g.
>> <https://gerrit.libreoffice.org/#/c/35258/> "replace double-checked-locking
>> with C++11 static initializer".
>
> Do we have any tinderbox building against the 10.8 SDK? I just realized
> that the xmlsec we bundle on master now requires libxml 2.8, and as far
> as I see Jenkins builds against the 10.9 SDK. So there is a risk that
> the 10.8 SDK provides an older libxml and this went unnoticed.

it got noticed today. the beta1 build faird for that very reason

the code use input_id of parserCtxt which was introduced in 2.8

that box use 10.8sdk which come with libxml:
#define LIBXML_DOTTED_VERSION "2.7.8"

Norbert
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Miklos Vajna-4 Miklos Vajna-4
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

Hi Norbert,

On Thu, May 18, 2017 at 01:11:38PM -0500, Norbert Thiebaud <[hidden email]> wrote:
> the code use input_id of parserCtxt which was introduced in 2.8
>
> that box use 10.8sdk which come with libxml:
> #define LIBXML_DOTTED_VERSION "2.7.8"

<https://gerrit.libreoffice.org/37812> is my attempt to address that.
We'll have to move to internal libxml in the long term though, xmlsec
upstream refused the patch, arguing libxml-2.8 was released 5 years ago,
so it's OK to depend on it.

Feedback on the above patch is appreciated, since Jenkins will mark the
patch as verified even if the 10.8 baseline is still broken.

Thanks,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (188 bytes) Download Attachment
Tor Lillqvist-2 Tor Lillqvist-2
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

In reply to this post by Norbert Thiebaud

that box use 10.8sdk which come with libxml:
#define LIBXML_DOTTED_VERSION "2.7.8"


In a current SDK it is 2.9.4. I don't know how it has been updated in SDK versions. But seriously, couldn't we bump the baseline to 10.9 by now? That would also help the thread-safe statics thing, if I understand correctly. Macs that can't be upgraded to 10.9 or beyond are about ten years old now, I think.

--tml
 

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Norbert Thiebaud Norbert Thiebaud
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

On Fri, May 19, 2017 at 5:58 AM, Tor Lillqvist <[hidden email]> wrote:

>
>> that box use 10.8sdk which come with libxml:
>> #define LIBXML_DOTTED_VERSION "2.7.8"
>>
>
> In a current SDK it is 2.9.4. I don't know how it has been updated in SDK
> versions. But seriously, couldn't we bump the baseline to 10.9 by now? That
> would also help the thread-safe statics thing, if I understand correctly.
> Macs that can't be upgraded to 10.9 or beyond are about ten years old now, I
> think.

I don't mind bumping to 10.9. the box that do the realease is already
at 10.9 anyway

according to google there are about 2 to 3% of mac users still on 10.8.
but hey.. if they are content with sticking to 10.8 they can be
content with sticking with lo 5.3

Norbert
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

On 05/19/2017 01:51 PM, Norbert Thiebaud wrote:
> I don't mind bumping to 10.9. the box that do the realease is already
> at 10.9 anyway

Note
<https://lists.freedesktop.org/archives/libreoffice/2017-April/077548.html>
"Minutes of ESC call ..."

> * Mac OS X 10.8 support (Michael S)
>     + the only platform that does not have thread safe statics
>       cf. https://bugs.documentfoundation.org/show_bug.cgi?id=93119
>     + de-facto unsupported by Apple since August 2015
>       https://support.apple.com/en-gb/HT201222
>     + Mozilla dropped support September 2016
>       https://support.mozilla.org/t5/Install-and-Update/Firefox-support-has-ended-for-Mac-OS-X-10-6-10-7-and-10-8/ta-p/32725
>     + Chrome dropped support April 2016
>       https://chrome.googleblog.com/2015/11/updates-to-chrome-platform-support.html
>     + deprecation warning in 5.4, and drop for 5.5? (Thorsten)
>         + around 2nd half of May
>         + OK to wait the month (Michael S.)
>         + shouldn’t block OS update (Cloph)
>         + support to wait 1 month (Kendy)
>     + needs some work on Android too (Miklos)
>         + toolchain update etc.
>         + but shouldn’t affect the runtime (Miklos)
>     + release note that etc. (Thorsten)

and resulting release notes update at
<https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F5.4&type=revision&diff=146397&oldid=146394>.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

In reply to this post by Miklos Vajna-4
On 03/16/2017 12:48 PM, Miklos Vajna wrote:

> On Thu, Mar 16, 2017 at 12:20:54PM +0100, Stephan Bergmann <[hidden email]> wrote:
>> Bumping this to macOS 10.9 would get rid of the last known case of
>> !HAVE_THREADSAFE_STATICS (cf. <https://cgit.freedesktop.org/libreoffice/core/commit/?id=aa2fbfc4faa24cf7ee5aa9afdafddbd536ac4fec>
>> "Found out that Mac OS X 10.9 has working threadsafe statics").  What is
>> unknown however is the status on Android and iOS.  Having
>> HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see e.g.
>> <https://gerrit.libreoffice.org/#/c/35258/> "replace double-checked-locking
>> with C++11 static initializer".
>
> master-android$ grep -R THREADSAFE config_*/*.h
> config_build/config_global.h:#define HAVE_THREADSAFE_STATICS 1
> config_host/config_global.h:#define HAVE_THREADSAFE_STATICS 0
>
> But this is not set in stone, quite possibly the Android toolchain (NDK,
> which provides the C++ cross-compiler) can be updated to a newer
> version, and then the problem will go away. (See
> "with_android_ndk_toolchain_version=4.9" in configure.ac.)

So after the recent bump to macOS 10.9, HAVE_THREADSAFE_STATICS should
effectively be true everywhere expect on Android (where configure.ac
doesn't bother at all to decide whether or not it would be true, always
leaving it false; either because it is known to be false for the current
Android baseline, or because those setting up Android support didn't
bother).

Can somebody clarify the actual situation on Android?
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Miklos Vajna-4 Miklos Vajna-4
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

Hi,

On Wed, May 31, 2017 at 11:27:16AM +0200, Stephan Bergmann <[hidden email]> wrote:
> So after the recent bump to macOS 10.9, HAVE_THREADSAFE_STATICS should
> effectively be true everywhere expect on Android (where configure.ac doesn't
> bother at all to decide whether or not it would be true, always leaving it
> false; either because it is known to be false for the current Android
> baseline, or because those setting up Android support didn't bother).
>
> Can somebody clarify the actual situation on Android?

As far as I can see it's the "because those setting up Android support
didn't bother" case. The attached patch does not break opening Writer
documents for me, so I guess it's safe to turn that "always false" to
"always true", as it happens on macOS.

Regards,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

patch (1K) Download Attachment
signature.asc (188 bytes) Download Attachment
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

On 05/31/2017 10:06 PM, Miklos Vajna wrote:
> As far as I can see it's the "because those setting up Android support
> didn't bother" case. The attached patch does not break opening Writer
> documents for me, so I guess it's safe to turn that "always false" to
> "always true", as it happens on macOS.

I don't think your experiment is telling much.  There are three cases to
consider:

1  A toolchain that doesn't support thread-safe statics.

2  A toolchain that correctly supports thread-safe statics.

3  A (dated GCC) toolchain that supports thread-safe statics, but in a
broken way (using a single lock for all static variables) that can lead
to deadlock.

To guard against kind 3, solenv/gbuild/platform/com_GCC_defs.mk adds
-fno-threadsafe-statics (to effectively turn the toolchain into kind 1)
when HAVE_THREADSAFE_STATICS is not true.

So your experiment (which would try to detect whether Android toolchains
are of kind 3) would probably also need to remove
-fno-threadsafe-statics from com_GCC_defs.mk (unless com_GCC_defs.mk
somehow isn't relevant for building on Android, anyway).

However, your experiment doesn't try to detect whether Android
toolchains are of kind 1.  (But it's probably safe to assume that they
are not if they use a GCC that supports -fthreadsafe-statics.)
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Miklos Vajna-4 Miklos Vajna-4
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

Hi Stephan,

On Thu, Jun 01, 2017 at 09:49:31AM +0200, Stephan Bergmann <[hidden email]> wrote:

> I don't think your experiment is telling much.  There are three cases to
> consider:
>
> 1  A toolchain that doesn't support thread-safe statics.
>
> 2  A toolchain that correctly supports thread-safe statics.
>
> 3  A (dated GCC) toolchain that supports thread-safe statics, but in a
> broken way (using a single lock for all static variables) that can lead to
> deadlock.
>
> To guard against kind 3, solenv/gbuild/platform/com_GCC_defs.mk adds
> -fno-threadsafe-statics (to effectively turn the toolchain into kind 1) when
> HAVE_THREADSAFE_STATICS is not true.
>
> So your experiment (which would try to detect whether Android toolchains are
> of kind 3) would probably also need to remove -fno-threadsafe-statics from
> com_GCC_defs.mk (unless com_GCC_defs.mk somehow isn't relevant for building
> on Android, anyway).
>
> However, your experiment doesn't try to detect whether Android toolchains
> are of kind 1.  (But it's probably safe to assume that they are not if they
> use a GCC that supports -fthreadsafe-statics.)
I repeated the experiment with
<https://gerrit.libreoffice.org/#/c/38296/> applied (so
HAVE_THREADSAFE_STATICS is TRUE in config_host.mk, also verified that
the generated commandline when compiling a C++ file contains no
-fno-threadsafe-statics), and also did a clean build, so all code is
built with the new compiler flags. I still see no deadlock up to the
point where a Writer document is rendered.

In addition, we build for Android using (currently) gcc-4.9, so 3) seems
to be out of question.

Does that help?

Regards,

Miklos

_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice

signature.asc (188 bytes) Download Attachment
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

In reply to this post by sberg
On 03/16/2017 12:20 PM, Stephan Bergmann wrote:

> *  macOS 10.8
> (<https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/4.4&oldid=99539#Mac_OS_X>)
>
>
> Bumping this to macOS 10.9 would get rid of the last known case of
> !HAVE_THREADSAFE_STATICS (cf.
> <https://cgit.freedesktop.org/libreoffice/core/commit/?id=aa2fbfc4faa24cf7ee5aa9afdafddbd536ac4fec>
> "Found out that Mac OS X 10.9 has working threadsafe statics").  What is
> unknown however is the status on Android and iOS.  Having
> HAVE_THREADSAFE_STATICS everywhere would allow to clean up code, see
> e.g. <https://gerrit.libreoffice.org/#/c/35258/> "replace
> double-checked-locking with C++11 static initializer".

So

* macOS baseline is bumped
(<https://cgit.freedesktop.org/libreoffice/core/commit/?id=7dcee9790c18a594236dc32a534c20f1e7447ee6>
"bumb MacOS baseline to 10.9")

* and all toolchains are now considered to have thread-safe statics
(<https://cgit.freedesktop.org/libreoffice/core/commit/?id=6517fd2107a5a71290afad8850da0eab51519bc6>
"HAVE_THREADSAFE_STATICS sould always be true")

(and writing typo-free commit messages is hard).
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

In reply to this post by Christian Lohmaier-3
On 03/29/2017 07:09 PM, Christian Lohmaier wrote:
> On Thu, Mar 16, 2017 at 12:20 PM, Stephan Bergmann <[hidden email]> wrote:
>> Some of our baselines on current master (towards LO 5.4) are as follows:
>> ** GCC 4.8.1:
>> *** inheriting constructors
>> *** ref-qualifiers
>
> FYI: baseline CentOS with devtoolset has 4.8.2

Is anybody actually still using GCC 4.7 on master (towards LO 6.0, by now)?

Just tried to build recent master against some GCC 4.7.4 (on F25, using
system's libstdc++ 6.3 at runtime), and that doesn't work well, causing
spurious -Wsign-compare warnings, spurious errors about allegedly
implicitly noexcept(false) dtors of std::exception derivations, and
failure to compile usage of thread_local in
comphelper/source/misc/threadpool.cxx (where support for thread-local
storage was only "partial" in GCC < 4.8, according to
<http://en.cppreference.com/w/cpp/compiler_support>).  So I wonder if
anybody still manages to build with anything less than GCC 4.8?

(LHM's tb56 appears to be using GCC 4.8 by now, and that used to be one
with a notoriously old compiler.)

If there's no objections, I'd bump current master towards LO 6.0 to GCC 4.8.
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

On 06/15/2017 03:34 PM, Stephan Bergmann wrote:

> On 03/29/2017 07:09 PM, Christian Lohmaier wrote:
>> On Thu, Mar 16, 2017 at 12:20 PM, Stephan Bergmann
>> <[hidden email]> wrote:
>>> Some of our baselines on current master (towards LO 5.4) are as follows:
>>> ** GCC 4.8.1:
>>> *** inheriting constructors
>>> *** ref-qualifiers
>>
>> FYI: baseline CentOS with devtoolset has 4.8.2
>
> Is anybody actually still using GCC 4.7 on master (towards LO 6.0, by now)?
>
> Just tried to build recent master against some GCC 4.7.4 (on F25, using
> system's libstdc++ 6.3 at runtime), and that doesn't work well, causing
> spurious -Wsign-compare warnings, spurious errors about allegedly
> implicitly noexcept(false) dtors of std::exception derivations, and
> failure to compile usage of thread_local in
> comphelper/source/misc/threadpool.cxx (where support for thread-local
> storage was only "partial" in GCC < 4.8, according to
> <http://en.cppreference.com/w/cpp/compiler_support>).  So I wonder if
> anybody still manages to build with anything less than GCC 4.8?
>
> (LHM's tb56 appears to be using GCC 4.8 by now, and that used to be one
> with a notoriously old compiler.)
>
> If there's no objections, I'd bump current master towards LO 6.0 to GCC
> 4.8.

(4.8.1 even, so we'll have ref-qualifiers known-working everywhere and
can drop HAVE_CXX11_REF_QUALIFIER.)
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice
sberg sberg
Reply | Threaded
Open this post in threaded view
|

Re: Some baseline thoughts

On 06/15/2017 03:45 PM, Stephan Bergmann wrote:
> On 06/15/2017 03:34 PM, Stephan Bergmann wrote:
>> If there's no objections, I'd bump current master towards LO 6.0 to
>> GCC 4.8.
>
> (4.8.1 even, so we'll have ref-qualifiers known-working everywhere and
> can drop HAVE_CXX11_REF_QUALIFIER.)

done now with
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=579497164f6bddfeb14bb6b0f4b9cd3322af1803>
"Bump GCC baseline to 4.8.1" and follow-up
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=468fc3847cfd65217949630e2ffd9fb0a89e9cbb>
"Work around GCC derivates with two-section 'gcc -dumpversion' output"
(and note

> Jun 16 13:20:56 <vmiklos>       sberg: is it an overkill to compile a small test program that reads __GNUC_PATCHLEVEL__ to avoid the need to assume things?
> Jun 16 13:47:43 <sberg> vmiklos, given <https://gcc.gnu.org/develop.html#num_scheme> and the changed version scheme since GCC 5, I'd just leave it at that; ref-qualifiers only available in 4.8.1 seems to be a rare exception where a feature only became available in a x.y.1 release, and we're still explicitly checking for existence of that feature independent of the GCC version we determine

about the latter)

consequently, also did
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=c127c19de62201b49b6647ef3ee8b08ae49da852>
"Remove HAVE_CXX11_REF_QUALIFIER, always true now"
_______________________________________________
LibreOffice mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/libreoffice