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
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
