Compiler baselines

Wed Nov 21 16:42:26 UTC 2018

With libreoffice-6-2 branched off, it is time again to look at the 
status of the below, so we will bump the baselines for current master 
towards LO 6.3 (tl;dr summary at the end):

On 13/09/2018 12:21, Stephan Bergmann wrote:
> * Building on CentOS 6 with DeveloperToolset (DTS) 7 (GCC 7.3.1) runs 
> into a linker issue with an unresolved 
> _ZN9__gnu_cxx32__throw_concurrence_unlock_errorEv when linking 
> Library_unoexceptionprotector in an --enable-dbgutil (i.e., 
> -D_GLIBCXX_DEBUG libstdc++ debug mode) build (see 
> <https://tinderbox.libreoffice.org/cgi-bin/gunzip.cgi?tree=MASTER&brief-log=1536396604.27182>). 
>   Smells like a bug in DTS's libstdc++_nonshared.a, but I learned 
> off-list that there is little hope that that would get fixed for DTS 7. 
> A hack-around I found to get at least Library_unoexceptionprotector 
> linked is to modify devtoolset-7-gcc-c++-7.3.1-5.10.el6.x86_64's 
> /opt/rh/devtoolset-7/root/usr/lib/gcc/x86_64-redhat-linux/7/libstdc++.so 
> linker script, doubling the -lstdc++_nonshared entry on the INPUT line.

All under control according to cloph; TDF (incl. Jenkins) Linux GCC 
master builds are done with DeveloperToolset 7.

> * Also saw that on CentOS 6 gperf-3.0.3-9.1.el6.x86_64 is too old, still 
> emitting register keywords in C++ mode, so that our configure.ac falls 
> back to using -std=gnu++14 instead of -std=gnu++17.  So the relevant 
> machines would also need a newer gperf (e.g., built from 
> gperf-3.1.tar.gz sources and passed into the LO build via a GPERF=... 
> line in autogen.input).

Fixed with 
<https://gerrit.libreoffice.org/plugins/gitiles/lode/+/3ce8f59fd916a5b2e1234d57023d8ae07262a5ff%5E%21/> 
"On Linux, use latest gperf 3.1", rolled out to all three relevant 
Jenkins nodes (tb75-lilith, tb76-maggie, tb79-pollux).

> * On macOS, our baseline is Xcode 8 according to 
> <https://cgit.freedesktop.org/libreoffice/core/commit/?id=1079893be5593268eff0867be87b0291546d88c7> 
> "Document baselines".  According to 
> <https://en.wikipedia.org/wiki/Xcode#Latest_versions> that means the 
> oldest Apple Clang we need to support corresponds roughly to Clang 3.9. 
> (Unfortunately, the information about what plain Clang the Apple Clang 
> shipped with Xcode corresponds to ends with Xcode 8.2.1 at 
> <https://en.wikipedia.org/wiki/Xcode#Latest_versions>, so it is not 
> immediately clear what benefit any update of our Xcode baseline would 
> bring us Clang-version wise.)

As discussed on FreeNode #libreoffice-dev today:

> Nov 21 12:28:39 <sberg> cloph_away, different question, do you know whether all the nodes used for Jenkins' gerrit_mac, i.e., the eight ones at <https://ci.libreoffice.org/label/macosx_clang_dbgutil/> all use the baseline Xcode 8?
> Nov 21 12:32:39 <cloph> No, they're not all using XCode 8
> Nov 21 12:40:43 <cloph> sberg: tb57, tb58, tb66: Xcode 9.3.1 – tb69: Xcode 9.4 – tb80, tb81: Xcode 9.4.1
> Nov 21 12:41:14 <cloph> (releases are done with 9.4.1)
> Nov 21 13:00:46 <sberg> cloph, so if all of them are on Xcode 9, there's no reason (from the Jenkins side, at least) to not also update the baseline to Xcode 9, right?
> Nov 21 13:02:14 <cloph> yes - don't even know whether xcode 8 would still be able to compile master...

So I would propose bumping the macOS build baseline from Xcode 8 to 
Xcode 9.3 (and staying on macOS 10.12).  The list at 
<https://en.wikipedia.org/wiki/Xcode#Latest_versions> has meanwhile been 
updated, showing that Xcode 9.3 and later use an Apple Clang that 
corresponds to plain Clang 5.0.2 or later.  Choosing that as a baseline 
for macOS comes in handy when choosing a Clang baseline for Linux, see next.

Using -std=c++17 or better on macOS will require a gperf that no longer 
emits "register", just as on Linux (see above). 
<https://gerrit.libreoffice.org/#/c/63728/> "Install gperf 3.1 if 
necessary", rolled out to the relevant macOS Jenkins nodes, will take 
care of that.

> * Regarding Clang on Linux, I saw the other day that e.g. Jenkins tb75 
> is still using Clang 3.8.  With macOS limiting us to 3.9, it would be 
> great if Linux would not limit us even more severely.  Does anybody have 
> a problem with upgrading the Clang-on-Linux baseline to at least 3.9 for 
> LO master in the near future?

I tried bumping Clang on the relevant Jenkins Linux nodes to 3.9.1 
(<https://gerrit.libreoffice.org/plugins/gitiles/lode/+/25290a596752cae943eb4774a2077e8de785f494%5E%21/> 
"On Linux, upgrade to Clang 3.9.1" and some follow-ups).  But configure 
then still only uses -std=gnu++11, because those systems' libstdc++ 
4.8.5 doesn't work well with Clang 3.9.1.  So similar to how 
DeveloperToolset 7 provides a libstdc++ 7 for GCC, I would install a 
"private" GCC 7.3.0 (which is the latest GCC 7 release) into the Jenkins 
lode configuration for Linux, and make Clang use that GCC 7.3.0 
libstdc++.  (I think we cannot use the DeveloperToolset libstdc++ for 
that, as that is only providing the delta to the system libstdc++, and 
needs compiler support.)  However, Clang 3.9.1 doesn't work well 
together with libstdc++ 7.3.0, so that configure would still choose 
-std=gnu++11.  Similar for Clang 4.0.1 (which would give us 
-std=gnu++14, but still not the C++17 support we are looking for).  Only 
starting with Clang 5 (where 5.0.2 is the latest release) we get 
-std=gnu++17 from the Clang 5.0.2 plus libstdc++ 7.3.0 combo.  The 
necessary lode changes are at 
<https://gerrit.libreoffice.org/#/c/63729/> "On Linux, upgrade to Clang 
5 plus libstdc++ 7".  So I would propose bumping the Linux Clang 
baseline to Clang 5.0.2 plus libstdc++ 7.3.0.

* For Clang compiler plugins, I would bump the baseline to 5.0.2 too. 
(Which would be the baseline on Linux anways, and even on macOS, though 
on macOS and Windows I think nobody but me uses Clang compiler plugins, 
and I always use Clang trunk there.)

* Using -std=c++17 or better will generally also require a flex that no 
longer emits "register", similar to the situation with gperf (see 
above).  So I would propse bumping the flex requirement (as checked in 
configure.ac) from 2.5.35 to 2.6.0.  See 
<https://gerrit.libreoffice.org/#/c/63713/> "Require at least flex 
2.6.0, which no longer emits 'register'" and the necessary lode changes 
at <https://gerrit.libreoffice.org/#/c/63727/> "Install flex 2.6.4 if 
necessary".

* For Windows, I would reactivate parked 
<https://gerrit.libreoffice.org/#/c/59209/> "On Windows, check for at 
least Visual Studio 2017 version 15.7" to bump the baseline from Visual 
Studio 2017 to Visual Studio 2017 version 15.7 (as already previously 
discussed elsewhere in this mail thread).

SUMMARY
=======

If nobody objects, we'd update the build baselines on master (towards LO 
6.3) as follows (cf README.md):

* Windows: from Visual Studio 2017 to Visual Studio 2017 version 15.7

* macOS: from Xcode 8 to Xcode 9.3

* Linux GCC: from GCC 4.8.1 to GCC 7

* Linux Clang: from Clang to Clang 5.0.2

* Clang compiler plugins: from Clang 3.8 to Clang 5.0.2

* flex: from 2.5.35 to 2.6.0

* gperf: from 3.0.0 to 3.1