Age | Commit message (Collapse) | Author |
|
Fixes CVE-2018-6942.
Remove freetype-msvc-disable-sse2.patch.1 (doesn't apply and freetype is
only used on Android).
Change-Id: Ia89329f758a077c1493cdea45f99e5f58d1ef265
Reviewed-on: https://gerrit.libreoffice.org/68087
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Not sure why the code has now started to require that, even if have
used the same bundled libpng as for a long time.
Change-Id: I2da223bc46c24563ce9d170643c28cc5c93f7d56
|
|
Change-Id: Ifbd3903494a81e7b155bf6468f6ca2c50b3370a4
Reviewed-on: https://gerrit.libreoffice.org/65958
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
In 3.0.4, the horrible makefiles override the CXXFLAGS variable:
firebird/builds/posix/prefix.linux_generic:CXXFLAGS=-std=gnu++03
Work around that by passing LO's customised CXXFLAGS as a command-line
parameter to make, which in turn overrides the definition in the
makefile.
Other platforms, in particular Darwin, apparently extend CXXFLAGS
instead of overwriting.
To nobody's surprise, gnu++03 doesn't even build with clang because ICU
headers use C++11 features (although strangely gcc doesn't complain).
Change-Id: If3b26482a4f4bf284057e261677cd7182656154f
Reviewed-on: https://gerrit.libreoffice.org/67255
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: I31f2ae004dac16aee05b258984e50795db2582cc
Reviewed-on: https://gerrit.libreoffice.org/67250
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This includes a revert of commit 9808486a89c6368f836579f8d8c0dda63fd0063c "Avoid
-Werror,-Wimplicit-fallthrough with clang-cl", and also undoes older MSVC
workarounds (that would start to cause "warning C4702: unreachable code" now).
Change-Id: If72bf336e12e0a2db589857e8875003dae861977
Reviewed-on: https://gerrit.libreoffice.org/67248
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Why do we need this?
Change-Id: I662402731de9b5c56d05730d31ae59606484ec97
Reviewed-on: https://gerrit.libreoffice.org/67210
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
commit c3ab3df902b9e2ad363d1eca14da8f9f7f1567bb
Date: Thu Oct 14 09:53:40 2010 +0200
changed the configure.ac to require "Patched by Libreoffice", which was
possibly an error
Change-Id: I6f8e302baeed054f36b54f8bfb6f5cad826ee788
Reviewed-on: https://gerrit.libreoffice.org/67199
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...as demanded by the C++17 standard, and required in
sc/source/core/tool/math.cxx. At least when building an --arch=i386 Flatpak
(where CFLAGS/CXXFLAGS are passed in containing, among others, -O2), that failed
when using -std=gnu++2a (instead of -std=c++2a) due to what looks like an error
in glibc (cf. <https://flathub.org/builds/#/builders/22/builds/797>).
...and fix fallout in external/firebird for Linux x86 32-bit build: While GCC
defines both __i386 and __i386__ (both as 1) regardless of -std=gnu++* vs.
-std=c++*, it defines i386 (as 1) only for -std=gnu++*. But various places in
the external/firebird sources check for i386 (among them src/common/common.h,
which fails with
#error Define FB_CPU for your platform
if i386 is not defined).
Change-Id: I7dce1961c79aeaccc82b1e2bdc350e02730d46af
Reviewed-on: https://gerrit.libreoffice.org/67105
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...(at least the original BOOST_GCC_VERSION part) as Boost 1.69.0
boost/config/workaround.hpp contains
> #ifndef BOOST_GCC
> #define BOOST_GCC_WORKAROUND_GUARD 1
> #define BOOST_GCC_VERSION_WORKAROUND_GUARD 1
> #else
> #define BOOST_GCC_WORKAROUND_GUARD 0
> #define BOOST_GCC_VERSION_WORKAROUND_GUARD 0
> #endif
Change-Id: I7690db147dbe776ff51b94fc9950b890bb290bda
Reviewed-on: https://gerrit.libreoffice.org/67000
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I84e969005ac2a96da449b5434ee5fdb37fc9b432
Reviewed-on: https://gerrit.libreoffice.org/66928
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Following https://cgit.freedesktop.org/libreoffice/core/commit/?id=02623af4f5e0049ec5988df8ff6c7ff0f32f3fb1
See details here:
http://document-foundation-mail-archive.969070.n3.nabble.com/fatal-error-LNK1561-on-nss-Visual-Studio-2017-td4256601.html
Change-Id: I75f2c8a5409e484a8a5a12a6f12d5c20b244d2b2
Reviewed-on: https://gerrit.libreoffice.org/67092
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The hope is that this should allow both system's libgpg-error.so.0 and
LO's bundled libgpg-error-lo.so.0 to be loaded by soffice.bin without
unintended hilarity.
Change-Id: I94498097a847b9756de86051798cb4ce022f6c83
Reviewed-on: https://gerrit.libreoffice.org/67012
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Fix regexp for cl.exe
This command returns some special characters preventing regexp to work.
For more details, see:
http://document-foundation-mail-archive.969070.n3.nabble.com/Could-not-determine-MSC-version-Visual-Studio-2017-td4256538.html
Change-Id: I734dcd533b0f38430d1be8852f1e4f721221e580
Reviewed-on: https://gerrit.libreoffice.org/66959
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which was at maximum set to GCC's -finline-limit=0 -fno-inline
(solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug
builds "since forever", but that looks very much like cargo cult: -fno-inline
"is the default when not optimizing" anyway
(<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it
is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline
(and maybe was present for ancient compilers that only supported -finline-limit
but not -fno-inline?).
Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874
Reviewed-on: https://gerrit.libreoffice.org/66836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...that is documented as: "Does nothing. Preserved for backward compatibility."
ever since <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=160384> from
2010.
-fno-default-inline was the only value ever set in gb_DEBUG_CXXFLAGS, so the
latter can be removed now.
The use of gb_DEBUG_CXXFLAGS had accidentally already been removed from
gb_LinkTarget__get_debugcxxflags with e751e24250fda31dde52b3c65ca79f86142dc789
"--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutil",
and that leaves gb_LinkTarget__get_debugcflags and
gb_LinkTarget__get_debugcxxflags with identical definitions, so replace those
two with a single gb_LinkTarget__get_debugflags.
Some external modules had used only gb_DEBUG_CXXFLAGS, when this was apparently
meant to be used in addition to gb_DEBUG_CFLAGS, so those uses have been changed
to gb_DEBUG_CFLAGS now.
Change-Id: I84ea0ab1233569b0b02ca057240a71f138352381
Reviewed-on: https://gerrit.libreoffice.org/66808
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Id771f1fe0d8c6702a52836f6229a944d259fed4c
Reviewed-on: https://gerrit.libreoffice.org/66424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
... at least, that's the plan - this is harder than it appears, as the
upstream maintainer appears to have released version 2.9 at least 3
times:
- Fedora has a file evidently downloaded before Nov. 17 with SHA512 of e30ad5a9a1ab9e7aaace9431434caa19a5ff6143db46644aba971a5ee37a265b26bf738e886d766405a7eb45a9d620d67c7ab3684ace86a107cf5a76642c04a5
- Gentoo has a file evidently downloaded before Nov. 19 with SHA256 of d4ad6f8718f7f9dc8b2a3276c9f237aa3f5eccdcf98b86dedc4262d8a1e7f009
- Debian has a file evidently downloaded before Dec. 17 with SHA256 of 48c6fdf98396fa245ed86e622028caf49b96fa22f3e5734f853f806fbc8e7d20
The lcms2-2.9.tar.gz available from sourceforge currently matches the
one Debian has, so let's use it.
* 0017-Upgrade-Visual-studio-2017-15.8.patch added (fixing CVE-2018-16435)
* 0001-Added-an-extra-check-to-MLU-bounds.patch.1 removed (fixed upstream)
Change-Id: Iab8dada8f6d77d5b2da8560993380b3332bc02f6
Reviewed-on: https://gerrit.libreoffice.org/66400
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: Ie4f0cc8f06432e182ce7ffcae5269075d12658ef
Reviewed-on: https://gerrit.libreoffice.org/66408
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
This reverts commit cc2bc0bf3cf75307aaa04f4dc8ddce8db678b450. As discussed at
<https://gerrit.libreoffice.org/#/c/55783/> "Fix nan is not a member of std when
building android":
Stephan: "with exactly what architecture and toolchain did that failure happen;
is this commit still relevant after <https://gerrit.libreoffice.org/plugins/
gitiles/core/+/312eeeee42cb4a1e356943e17305555e41afc4ef%5E!/> 'Switch Android
armeabi-v7a to libc++/libc++abi/libunwind too'?"
Tomaž: "It was a consequence of that limited Bionic libstdc++ that was used in
ANdorid. libc++ should be a modern up-to-date replacements so I guess this
workaraunds are now obsolete and irrelevant."
(And a --with-distro=LibreOfficeAndroid build against NDK r16b indeed succeeded
for me with this revert.)
Conflicts:
external/libwps/UnpackedTarball_libwps.mk
Change-Id: I2dba64e5712b20fa07f6374ae01c226025c52d8b
Reviewed-on: https://gerrit.libreoffice.org/66390
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after 23a8d5ffbbe58761b89f590f0735abccd69a3681 "Upgrade external/boost to
Boost 1.69.0", where at least some GCC versions apparently choke on -Wundef
there even though going through external/boost/include/boost/optional.hpp with
#pragma GCC diagnostic ignored "-Wundef"
(<https://ci.libreoffice.org/job/lo_tb_master_linux_dbg/23929/>):
> In file included from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/workdir/UnpackedTarball/boost/boost/core/explicit_operator_bool.hpp:22:0,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/workdir/UnpackedTarball/boost/boost/optional/optional.hpp:30,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/external/boost/include/boost/optional/optional.hpp:27,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/workdir/UnpackedTarball/boost/boost/optional.hpp:15,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/external/boost/include/boost/optional.hpp:27,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/vcl/outdevstate.hxx:31,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/vcl/outdev.hxx:39,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/vcl/window.hxx:25,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/vcl/ctrl.hxx:25,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/include/vcl/fixed.hxx:25,
> from /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/comphelper/source/misc/xmlsechelper.cxx:25:
> /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/workdir/UnpackedTarball/boost/boost/type_traits/detail/config.hpp:85:69: error: "__clang_major___WORKAROUND_GUARD" is not defined, evaluates to 0 [-Werror=undef]
> && !BOOST_WORKAROUND(BOOST_MSVC, < 1900) && !BOOST_WORKAROUND(__clang_major__, <= 4)
> ^
> /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/workdir/UnpackedTarball/boost/boost/config/workaround.hpp:253:10: note: in definition of macro ‘BOOST_WORKAROUND’
> ((symbol ## _WORKAROUND_GUARD + 0 == 0) && \
> ^~~~~~
> /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/workdir/UnpackedTarball/boost/boost/type_traits/detail/config.hpp:85:69: error: "__clang_major__" is not defined, evaluates to 0 [-Werror=undef]
> && !BOOST_WORKAROUND(BOOST_MSVC, < 1900) && !BOOST_WORKAROUND(__clang_major__, <= 4)
> ^
> /home/tdf/lode/jenkins/workspace/lo_tb_master_linux_dbg/workdir/UnpackedTarball/boost/boost/config/workaround.hpp:254:9: note: in definition of macro ‘BOOST_WORKAROUND’
> (symbol != 0) && (1 % (( (symbol test) ) + 1)))
> ^~~~~~
Change-Id: I9fe6bf0019fcddad7e1b5606a162474130a9250e
Reviewed-on: https://gerrit.libreoffice.org/66349
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I44e969d8d3a8fe6b6426d61a1cbe83154c8518dd
Reviewed-on: https://gerrit.libreoffice.org/66329
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
* fixes CVE-2018-14404
* drop one hunk from libxml2-android.patch that was added in commit
6a17d2f2ba7acfec277314b97b50e41532d6b44d; presumably nan() exists now
given that other code is calling it.
Change-Id: I696cc4e1da55536ea1c89a6e0446ce5bc8398ba4
Reviewed-on: https://gerrit.libreoffice.org/66308
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: If20998f8565b5534a96b3f29ccec572273edca1d
Reviewed-on: https://gerrit.libreoffice.org/66306
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
<https://dev-www.libreoffice.org/src/boost_1_69_0.tar.bz2> is a copy of
<https://dl.bintray.com/boostorg/release/1.69.0/source/boost_1_69_0.tar.bz2>,
SHA256 hash as given at <https://www.boost.org/users/download/>.
* removed from external/boost/include/boost/ those files that are no longer
present in workdir/UnpackedTarball/boost/boost/
* the shrunk external/boost/rtti.patch.0 can probably be removed completely in a
follow-up commit
* the patch to libs/filesystem/src/operations.cpp in
external/boost/boost-android-unified.patch.1 no longer applied, and appears to
be no longer necessary anyway (seeing a working build without it of
--with-distro=LibreOfficeAndroid and NDK r16b); but with the non-standard
Clang 5.0.300080 from NDK r16b, the build now caused failures like
> workdir/UnpackedTarball/boost/boost/type_traits/detail/is_function_cxx_11.hpp:36:11: error: class template partial specialization contains a template parameter that cannot be deduced; this partial specialization will never be used [-Wunusable-partial-specialization]
> struct is_function<Ret BOOST_TT_DEF_CALL(Args...)BOOST_TT_NOEXCEPT_DECL> : public true_type {};
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> workdir/UnpackedTarball/boost/boost/type_traits/detail/is_function_cxx_11.hpp:35:38: note: non-deducible template parameter 'NE'
> template <class Ret, class...Args BOOST_TT_NOEXCEPT_PARAM>
> ^
> workdir/UnpackedTarball/boost/boost/type_traits/detail/is_function_cxx_11.hpp:22:40: note: expanded from macro 'BOOST_TT_NOEXCEPT_PARAM'
> #define BOOST_TT_NOEXCEPT_PARAM , bool NE
> ^
showing that that version of Clang has the same problem handling noexcept(b)
as a deduced template parameter as MSVC has, as already supported by the code
* new external/boost/sse.patch.0 needed on Windows x86 to silence errors like
> C:\cygwin\home\tdf\lode\jenkins\workspace\gerrit_windows\workdir\UnpackedTarball\boost\boost/type_traits/detail/is_function_cxx_11.hpp(111): error C2215: '__vectorcall' cannot be used with '/arch:SSE'
(<https://ci.libreoffice.org/job/gerrit_windows/26117/>); according to
<https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros
?view=vs-2017>: "_M_IX86_FP Defined as an integer literal value that indicates
the /arch compiler option that was set, or the default. This macro is always
defined when the compilation target is an x86 processor. Otherwise, undefined.
When defined, the value is: [...] 1 if the /arch:SSE compiler option was set."
and we specify /arch:SSE explicitly for Windows x86 since
8bd6bf93b7711a7ac7c5cbd7c3bb980481570ebd "fdo#82430: configure: MSVC build:
avoid using SSE2 instructions"
* boost::logic::tribool conversion operator to bool is explicit now
Change-Id: Iea49560d734f545539f062dce46740fbf812dd84
Reviewed-on: https://gerrit.libreoffice.org/66189
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The corresponding <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679>
"[5 Regression] Strange uninitialized warning after SRA" is claimed to be fixed
in GCC 6, so should no longer be needed (with our current baseline of GCC 7).
Change-Id: Ia9435dbf6644639961094d6bfb47e47500ab70b7
Reviewed-on: https://gerrit.libreoffice.org/66181
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I2b99cd30b151eaa0302abaa9fdfa92fe8300a4d5
|
|
We don't run them and building them takes a while, especially with -j1.
Old time: 2m35,809s
New time: 1m12,858s
(With ccache disabled.) I.e. 47% of baseline.
Change-Id: I3e2d75b27be3c5995b5e6db9812c9f82d33f42fd
Reviewed-on: https://gerrit.libreoffice.org/65843
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
Change-Id: Iac2c3f75eda07b7381e57dba389c9836ab26502f
Reviewed-on: https://gerrit.libreoffice.org/65781
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I01454cc35baf96743bd19e64dd3a7269c58621bf
Reviewed-on: https://gerrit.libreoffice.org/65715
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I68e3791f50b95956bfe6aae743978994a5f232b4
Reviewed-on: https://gerrit.libreoffice.org/65714
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
..."target does not support '.file' without a number", which was introduced into
LLVM with <http://llvm.org/viewvc/llvm-project?view=revision&revision=349976>
"[MC] Enable .file support on COFF and diagnose it on unsupported targets",
stating: "The 'single parameter' .file directive appears to be an ELF-only
featurea [sic] that is intended to insert the main source filename into the
string table table [sic]."
And <https://sourceware.org/binutils/docs-2.31/as/File.html> states about the
default single (file name) argument version: "This statement may go away in
future: it is only recognized to be compatible with old as programs."
As external/python3 builds just fine on macOS with that .file directive removed,
lets just do that for now.
Change-Id: Ib28c29d0cacd151437447ccb2f6cfb8925e3e85a
Reviewed-on: https://gerrit.libreoffice.org/65704
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ib29e1a622e25731731512a695443ac2c530d30c2
Reviewed-on: https://gerrit.libreoffice.org/65701
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Since TWAIN is only actually available as 32-bit component on Windows,
to use it in a 64-bit program, we need a 32-bit shim program that does
all actual communication with TWAIN subsystem.
This change reimplements TWAIN implementation to be a separate 32-bit
process. Image is transfered from the shim to main program using file
mapping API.
This reverts most of commit 585d9806961342e95f7318fb947bd31e9f86dee0.
64-bit LibreOffice doesn't bundle TWAIN DSM library now. TWAIN DSM
source code is still used for TWAIN headers.
Change-Id: I46f178ad36acd97a9eff156624b99036fcbb83f8
Reviewed-on: https://gerrit.libreoffice.org/65688
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I0a7e888af770a332e2fec057507eecebf83621c4
Reviewed-on: https://gerrit.libreoffice.org/65646
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: Ib4d546f1e44eb6a682ec7cbbaab7a0a2050ffa1c
Reviewed-on: https://gerrit.libreoffice.org/65377
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...which had been removed completely with
6b84708914f9c026776b28a300ac6d278272881f "graphite: update to 1.3.12". See
<https://ci.libreoffice.org/job/lo_ubsan/1137/>:
> /workdir/UnpackedTarball/graphite/src/gr_face.cpp:98:16: runtime error: downcast of address 0x60f00008c3b0 which does not point to an object of type 'gr_face'
> 0x60f00008c3b0: note: object is of type 'graphite2::Face'
> 2a 00 00 61 d0 17 e7 ff 99 2b 00 00 36 00 be be be be be be 88 d8 0e 00 d0 61 00 00 80 38 05 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'graphite2::Face'
> #0 0x2b99fdaae105 in gr_make_face_with_ops /workdir/UnpackedTarball/graphite/src/gr_face.cpp:98:16
> #1 0x2b99fdaaeabe in gr_make_face /workdir/UnpackedTarball/graphite/src/gr_face.cpp:107:12
> #2 0x2b99fdfd6dc7 in _hb_graphite2_shaper_face_data_create /workdir/UnpackedTarball/harfbuzz/src/hb-graphite2.cc:114:18
> #3 0x2b99fdfd62f0 in hb_graphite2_shaper_face_data_ensure /workdir/UnpackedTarball/harfbuzz/src/hb-graphite2.cc:37:1
> #4 0x2b99fddb6a10 in hb_shape_plan_create_cached2 /workdir/UnpackedTarball/harfbuzz/src/./hb-shaper-list.hh:35:1
> #5 0x2b99fddb1478 in hb_shape_full /workdir/UnpackedTarball/harfbuzz/src/hb-shape.cc:133:33
> #6 0x2b99fc5867df in GenericSalLayout::LayoutText(ImplLayoutArgs&, SalLayoutGlyphs const*) /vcl/source/gdi/CommonSalLayout.cxx:440:23
> #7 0x2b99fb2345e4 in OutputDevice::ImplLayout(rtl::OUString const&, int, int, Point const&, long, long const*, SalLayoutFlags, vcl::TextLayoutCache const*, SalLayoutGlyphs const*) const /vcl/source/outdev/text.cxx:1310:36
> #8 0x2b99fb236220 in OutputDevice::GetTextArray(rtl::OUString const&, long*, int, int, vcl::TextLayoutCache const*, SalLayoutGlyphs const*) const /vcl/source/outdev/text.cxx:960:45
> #9 0x2b99fb235c56 in OutputDevice::GetTextWidth(rtl::OUString const&, int, int, vcl::TextLayoutCache const*, SalLayoutGlyphs const*) const /vcl/source/outdev/text.cxx:881:19
> #10 0x2b99fd105281 in ImplFontMetricData::ImplInitTextLineSize(OutputDevice const*) /vcl/source/font/fontmetric.cxx:325:30
> #11 0x2b99fb1c128c in OutputDevice::ImplNewFont() const /vcl/source/outdev/font.cxx:1062:38
> #12 0x2b99fb1bd46c in OutputDevice::GetFontFeatures(std::__debug::vector<vcl::font::Feature, std::allocator<vcl::font::Feature> >&) const /vcl/source/outdev/font.cxx:171:10
> #13 0x2b9a1a3c8607 in FontFeatureTest::testGetFontFeatures() /vcl/qa/cppunit/FontFeatureTest.cxx:58:5
> #14 0x2b9a1a401f2c in void std::__invoke_impl<void, void (FontFeatureTest::*&)(), FontFeatureTest*&>(std::__invoke_memfun_deref, void (FontFeatureTest::*&)(), FontFeatureTest*&) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/invoke.h:73:14
> #15 0x2b9a1a401b0f in std::__invoke_result<void (FontFeatureTest::*&)(), FontFeatureTest*&>::type std::__invoke<void (FontFeatureTest::*&)(), FontFeatureTest*&>(void (FontFeatureTest::*&)(), FontFeatureTest*&) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/invoke.h:95:14
> #16 0x2b9a1a40195c in void std::_Bind<void (FontFeatureTest::* (FontFeatureTest*))()>::__call<void, 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/functional:467:11
> #17 0x2b9a1a401533 in void std::_Bind<void (FontFeatureTest::* (FontFeatureTest*))()>::operator()<void>() /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/functional:549:17
> #18 0x2b9a1a400340 in std::_Function_handler<void (), std::_Bind<void (FontFeatureTest::* (FontFeatureTest*))()> >::_M_invoke(std::_Any_data const&) /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/std_function.h:316:2
> #19 0x2b9a1a40259c in std::function<void ()>::operator()() const /home/tdf/lode/opt_private/gcc-7.3.0/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../include/c++/7.3.0/bits/std_function.h:706:14
> #20 0x2b9a1a3ff580 in CppUnit::TestCaller<FontFeatureTest>::runTest() /workdir/UnpackedTarball/cppunit/include/cppunit/TestCaller.h:175:7
> #21 0x2b99d930dab8 in CppUnit::TestCaseMethodFunctor::operator()() const /workdir/UnpackedTarball/cppunit/src/cppunit/TestCase.cpp:32:5
> #22 0x2b99f39cf332 in (anonymous namespace)::Protector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) /test/source/vclbootstrapprotector.cxx:49:14
> #23 0x2b99d92de5fa in CppUnit::ProtectorChain::ProtectFunctor::operator()() const /workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:20:25
> #24 0x2b99e850d672 in (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) /unotest/source/cpp/unobootstrapprotector/unobootstrapprotector.cxx:89:12
> #25 0x2b99d92de5fa in CppUnit::ProtectorChain::ProtectFunctor::operator()() const /workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:20:25
> #26 0x2b99e5130312 in (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) /unotest/source/cpp/unoexceptionprotector/unoexceptionprotector.cxx:63:16
> #27 0x2b99d92de5fa in CppUnit::ProtectorChain::ProtectFunctor::operator()() const /workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:20:25
> #28 0x2b99d9273d82 in CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) /workdir/UnpackedTarball/cppunit/src/cppunit/DefaultProtector.cpp:15:12
> #29 0x2b99d92de5fa in CppUnit::ProtectorChain::ProtectFunctor::operator()() const /workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:20:25
> #30 0x2b99d92d7f02 in CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) /workdir/UnpackedTarball/cppunit/src/cppunit/ProtectorChain.cpp:86:18
> #31 0x2b99d93705e5 in CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /workdir/UnpackedTarball/cppunit/src/cppunit/TestResult.cpp:182:28
> #32 0x2b99d930c135 in CppUnit::TestCase::run(CppUnit::TestResult*) /workdir/UnpackedTarball/cppunit/src/cppunit/TestCase.cpp:91:13
> #33 0x2b99d930ff12 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) /workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:64:30
> #34 0x2b99d930f0ed in CppUnit::TestComposite::run(CppUnit::TestResult*) /workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:23:3
> #35 0x2b99d930ff12 in CppUnit::TestComposite::doRunChildTests(CppUnit::TestResult*) /workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:64:30
> #36 0x2b99d930f0ed in CppUnit::TestComposite::run(CppUnit::TestResult*) /workdir/UnpackedTarball/cppunit/src/cppunit/TestComposite.cpp:23:3
> #37 0x2b99d939eb32 in CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) /workdir/UnpackedTarball/cppunit/src/cppunit/TestRunner.cpp:47:27
> #38 0x2b99d936f075 in CppUnit::TestResult::runTest(CppUnit::Test*) /workdir/UnpackedTarball/cppunit/src/cppunit/TestResult.cpp:149:9
> #39 0x2b99d939fa80 in CppUnit::TestRunner::run(CppUnit::TestResult&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /workdir/UnpackedTarball/cppunit/src/cppunit/TestRunner.cpp:96:14
> #40 0x543813 in (anonymous namespace)::ProtectedFixtureFunctor::run() const /sal/cppunittester/cppunittester.cxx:316:20
> #41 0x54027d in sal_main() /sal/cppunittester/cppunittester.cxx:466:20
> #42 0x53f26e in main /sal/cppunittester/cppunittester.cxx:373:1
> #43 0x2b99daec8444 in __libc_start_main (/lib64/libc.so.6+0x22444)
> #44 0x42f454 in _start (/workdir/LinkTarget/Executable/cppunittester+0x42f454)
>
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /workdir/UnpackedTarball/graphite/src/gr_face.cpp:98:16 in
>
> Error: a unit test failed, please do one of:
>
> make CppunitTest_vcl_fontfeature CPPUNITTRACE="gdb --args"
> # for interactive debugging on Linux
> make CppunitTest_vcl_fontfeature VALGRIND=memcheck
> # for memory checking
> make CppunitTest_vcl_fontfeature DEBUGCPPUNIT=TRUE
> # for exception catching
>
> You can limit the execution to just one particular test by:
>
> make CPPUNIT_TEST_NAME="testXYZ" ...above mentioned params...
>
> /home/tdf/lode/jenkins/workspace/lo_ubsan/solenv/gbuild/CppunitTest.mk:113: recipe for target '/home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/CppunitTest/vcl_fontfeature.test' failed
Change-Id: Iccb72ec8a4c507478858ceb5af32b75f5ae53a45
Reviewed-on: https://gerrit.libreoffice.org/65226
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Martin Hosken thinks all patches are redundant now, so drop them.
Change-Id: I062168416a1289b7f4dd42d8ae58b7df56a37712
Reviewed-on: https://gerrit.libreoffice.org/65074
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
(which otherwise always defaults to --enable-werror)
Change-Id: If0e430e0d0994088a61843ea8f3759adbc993be6
Reviewed-on: https://gerrit.libreoffice.org/65075
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(which otherwise always defaults to --enable-werror)
Change-Id: I928277cec62dd36da0b18eb622ee91c176c9ccc6
Reviewed-on: https://gerrit.libreoffice.org/65072
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
It had been left out in 4082a18406c18af7b4fcef7bd501c3679c3be56b "android: use
unified headers and llvm-c++ STL (x86) with NDK 16" because "arm unfortunately
crashes with llvm-c++, so keep with gnustl for now/fix that later".
Making armeabi-v7a work with libc++ etc. required a number of changes, listed
below, in this commit and in preceding ones. At least 32-bit x86 already worked
with libc++ etc. prior to these changes in view mode, though it crashed in the
experimental editing mode (enabled with strippedUIEditing in
android/soruce/Makefile) as soon as one types in something, But it is not
entirely clear to me why 32-bit x86 view mode didn't also fail similar to how I
saw armeabi-v7a fail. (On 32-bit x86, these changes appear to neither improve
nor worsen the current state, view mode still appears to work fine while editing
still crashes upon typing anything. With these changes, editing mode on
armeabi-v7a appears to work fine. But I tested armeabi-v7a only with a real
device and 32-bit x86 only with an emulator, in case that might make a
difference.)
* Preceding <https://gerrit.libreoffice.org/#/c/64964/> "Move NSSLIBS to a more
sensible place on the linker command line" plus this change's addition of
-lunwind to the liblo-native-code.so linker command line make sure that
liblo-native-code.so uses _Unwind_* functions from libunwind.a, instead of
erroneously picking up the ones from libgcc.a that happen to be included in
NSSLIB's nspr4 (-lgcc is automatically added to the end of the linker command
line by the invoking compiler, that's how libgcc.a's _Unwind_* end up in
NSSLIB's nspr4; it is neither clear to me why NSSLIB's nspr4, being a pure C
library, uses _Unwind_* functions, nor why exception handling in
liblo-native-code.so fails when using _Unwind_* functions from libgcc.a
instead of from libunwind on armeabi-v7a, nor why that would work on 32-bit
x86, but that's what I observed: ModuleManager::identify
(framework/source/services/modulemanager.cxx) throws a
css::lang::IllegalArgumentException, which calls __cxa_throw ->
_Unwind_RaiseException, which ultimately lead to odd misbehavior and
std::abort during stack unwinding when using _Unwind_RaiseException from
libgcc.a instead of from libunwind). (There is no libunwind.* in
android-ndk-r16b for 32-bit x86 at least, so is presumably using _Unwind_*
functions from libgcc.a. It doesn't appear to make a difference if it
indirectly uses those _Unwind_* functions from NSSLIB's nspr4, or directly
from libgcc.a included in liblo-native-code.so if the
$(if $(filter armeabi-v7a,$(ANDROID_APP_ABI)),-lunwind)
had a ",-lgcc" else branch.)
* Preceding <https://gerrit.libreoffice.org/#/c/64965/> "Export RTTI symbols
from liblo-native-code.so, for binary UNO bridge" makes sure that excpetions
thrown from the binary UNO bridge can be caught by compiled catch clauses.
Not sure why the corresponding state of
bridges/source/cpp_uno/gcc3_linux_intel shouldn't have run into the same
issue.
* Preceding <https://gerrit.libreoffice.org/#/c/64966/> "Adapt gcc3_linux_arm
__cxa_exception to NDK 18 libc++abi" makes sure that our version of
__cxa_exception matches the version from libc++abi. This is clearly not
relevant for 32-bit x86. (The comment there android-ndk-r18b, but the
additional member is already present in
android-ndk-r16b/sources/cxx-stl/llvm-libc++abi/src/cxa_exception.hpp, too.)
The remainder of this change just drops old armeabi-v7a--specific workarounds
that are no longer needed/no longer work.
Change-Id: Ief4c2d562c5032abe6c3b94ca3b3394be6fcd4d3
Reviewed-on: https://gerrit.libreoffice.org/64973
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(See 1d028d4783da69c5c0e6e0b59e0f8ac55eb9d2b1 "Fix Linux RPATH of various
external modules" for the original external/coinmp/rpath.patch missing a patch
for CoinUtils/configure.) This is a blind fix attempt for
<https://ci.libreoffice.org/job/lo_daily_update_gandalf/559/console>
> /lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/instdir/program/libCoinUtils.so.3 has unexpected RPATH 0x000000000000001d (RUNPATH) Library runpath: [/opt/rh/devtoolset-7/root/usr/lib/../lib64:$ORIGIN]
> /lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/postprocess/CustomTarget_check_dynamic_objects.mk:20: recipe for target '/lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/workdir/CustomTarget/postprocess/check_dynamic_objects/check.done' failed
after ed81fe44d4e6b36c4c61a22e9e28a3a94fef9238 "Enabling Developer Toolset 7 for
Jenkins' remaining GCC master jobs" enabled GCC 8 at gandalf's
/opt/rh/devtoolset-7/root/ (which is at the same location as a CentOS Developer
Toolset 7 special GCC 7, but is actually a plain GCC 8, cf.
<https://lists.freedesktop.org/archives/libreoffice/2018-December/081544.html>
"Re: Compiler baselines") for the lo_daily_update_gandalf job. Presumably
libtool added to RPATH a path to find that GCC 8 installation's
/opt/rh/devtoolset-7/root/usr/lib64/libstdc++.so.6.
Change-Id: I37c98faffe3e6c014e321b756a18a8468c32877c
Reviewed-on: https://gerrit.libreoffice.org/64942
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(See 1d028d4783da69c5c0e6e0b59e0f8ac55eb9d2b1 "Fix Linux RPATH of various
external modules" for the similar patches to other external projects.) This is
a blind fix attempt for
<https://ci.libreoffice.org/job/lo_daily_update_gandalf/559/console>
> /lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/instdir/program/librevenge-0.0-lo.so.0 has unexpected RPATH 0x000000000000001d (RUNPATH) Library runpath: [/opt/rh/devtoolset-7/root/usr/lib/../lib64]
[...]
> /lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/postprocess/CustomTarget_check_dynamic_objects.mk:20: recipe for target '/lo/home/tdf/lode/jenkins/workspace/lo_daily_update_gandalf/workdir/CustomTarget/postprocess/check_dynamic_objects/check.done' failed
after ed81fe44d4e6b36c4c61a22e9e28a3a94fef9238 "Enabling Developer Toolset 7 for
Jenkins' remaining GCC master jobs" enabled GCC 8 at gandalf's
/opt/rh/devtoolset-7/root/ (which is at the same location as a CentOS Developer
Toolset 7 special GCC 7, but is actually a plain GCC 8, cf.
<https://lists.freedesktop.org/archives/libreoffice/2018-December/081544.html>
"Re: Compiler baselines") for the lo_daily_update_gandalf job. Presumably
libtool added to RPATH a path to find that GCC 8 installation's
/opt/rh/devtoolset-7/root/usr/lib64/libstdc++.so.6.
Change-Id: I18a88b2dcdfcaf2e2d36d5ee1b41ce865e4ac34e
Reviewed-on: https://gerrit.libreoffice.org/64943
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...now that /Zc:__cplusplus is available in Visual Studio 2017 version 15.7
(see <https://blogs.msdn.microsoft.com/vcblog/2018/04/09/
msvc-now-correctly-reports-__cplusplus/>).
Some external projects might run into issues when picking up /Zc:__cplusplus
directly with $(CXXFLAGS_CXX11) or indirectly via $(gb_CXXFLAGS) now, but that
appears not to be the case.
Some obsolete MSVC-specific __cplusplus checks can be removed now. (The ones in
external/libebook/libebook-msvc.patch.1 pick up /Zc:__cplusplus via
$(gb_CXXFLAGS) in external/libebook/ExternalProject_libebook.mk.)
Change-Id: Idc6849a0000ea424522f30f61caba112fae25d40
Reviewed-on: https://gerrit.libreoffice.org/64755
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which is the latest 9.2.x currently listed at
<https://www.postgresql.org/ftp/source/>. 9.2.1 doesn't build against
OpenSSL 1.1 which dropped SSL_library_init (cf. <https://wiki.openssl.org/
index.php/Library_Initialization#libssl_Initialization>), and 9.2.24 apparently
has that covered. (Ran into this when trying to upgrade the LibreOffice flatpak
build to org.freedesktop.Sdk//18.08, which has OpenSSL 1.1.)
On Windows, the new tarball as-is fails with
> ..\..\port\chklocale.c(214): error C2037: left of 'lc_codepage' specifies undefined struct/union '__crt_locale_data'
because at least in Windows Kits/10/Include/10.0.17763.0/ucrt/corecrt.h
(included from Windows Kits/10/Include/10.0.17763.0/ucrt/locale.h), the relevant
definitions are now
> typedef struct __crt_locale_data_public
> {
> unsigned short const* _locale_pctype;
> _Field_range_(1, 2) int _locale_mb_cur_max;
> unsigned int _locale_lc_codepage;
> } __crt_locale_data_public;
>
> typedef struct __crt_locale_pointers
> {
> struct __crt_locale_data* locinfo;
> struct __crt_multibyte_data* mbcinfo;
> } __crt_locale_pointers;
>
> typedef __crt_locale_pointers* _locale_t;
which presumably has changed from a past state where that lc_codepage member was
directly publicly accessible.
<https://dev-www.libreoffice.org/src/postgresql-9.2.24.tar.bz2> is a copy of
<https://ftp.postgresql.org/pub/source/v9.2.24/postgresql-9.2.24.tar.bz2>;
`sha256sum postgresql-9.2.24.tar.bz2` reports the same
a754c02f7051c2f21e52f8669a421b50485afcde9a581674d6106326b189d126 as recorded in
<https://ftp.postgresql.org/pub/source/v9.2.24/postgresql-9.2.24.tar.bz2.sha256>
Change-Id: I196dd93aa03471042efba57ea639e1bb6655de98
Reviewed-on: https://gerrit.libreoffice.org/64730
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I56c68b74daa701e0e27ca4b661ece12bf20a8776
Reviewed-on: https://gerrit.libreoffice.org/64729
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9130d0d1fceeb6efb1f324c99acd38eb92e67850
Reviewed-on: https://gerrit.libreoffice.org/64733
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...ever since f1579d3d6c5f5f3a651825e035b93bee7a4f43c6 "tdf#117171 support
localized number name numbering styles"
Change-Id: I93dcfa9f1310b35e3068a7e0efdce258364a7d78
Reviewed-on: https://gerrit.libreoffice.org/64720
Reviewed-by: László Németh <nemeth@numbertext.org>
Tested-by: László Németh <nemeth@numbertext.org>
Tested-by: Jenkins
|
|
...after <https://gerrit.libreoffice.org/63951> "Bump (Linux) GCC baseline to
7.0.0". (In some cases, those checks now need to check for __clang__, which was
implicitly covered in the past by Clang consistently reporting to be
GCC 4.2.1.)
Change-Id: I860fef8c4ca41c22a7541f0fb2d34b37d1d69bed
Reviewed-on: https://gerrit.libreoffice.org/63952
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...after 206b8c4ae320d7d8614f21800d8f77fa29f8f5ff "On Windows, check for at
least Visual Studio 2017 version 15.7"
Change-Id: I38ee86e1649bbdc828a7e328f2dbbac0dc163c8a
Reviewed-on: https://gerrit.libreoffice.org/64250
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|