update:
* 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.
* 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).
* On Windows, found out that guaranteed copy elision support isn't good
enough for our needs (see
<https://cgit.freedesktop.org/libreoffice/core/commit/?id=62bfe29f9045127d479c42376f599ddfb0fbb2ca>
"Already set MSVC's -std:c++17 during the configure.ac feature checks")
even in latest MSVC 2017 15.8, even though
<https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B17_features>
advertises it as supported since MSVC 2017 15.6. Apparently a reminder
to treat the feature matrix at
<https://en.cppreference.com/w/cpp/compiler_support> with a grain of salt...
* 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.)
* 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?
* A real-life example I came across today at
<https://gerrit.libreoffice.org/#/c/60394/3..4/xmloff/source/draw/animexp.cxx>
of a benefit we would get from a baseline bump is the current lack of
support for inline variables with some compilers (necessitating those
!HAVE_CPP_INLINE_VARIABLES extra variable definitions to be sprinkled
throughout the code). Per
<https://en.cppreference.com/w/cpp/compiler_support#C.2B.2B17_features>,
inline variables are supported by GCC 7, Clang 3.9, and MSVC 2017 15.5
(and, I can confirm, are indeed supported fine for our needs with at
least MSVC 2017 15.8).
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
