Age | Commit message (Collapse) | Author |
|
Change-Id: Ibf358e42f6411777819d0f46a4fe93c9b5ed9594
Reviewed-on: https://gerrit.libreoffice.org/56975
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
First of all, lld doesn't have these options, but there doesn't seem
to be any point in using them anyway. They are supposed to block
the effect of -Bsymbolic-functions, but:
- --dynamic-list-cpp-new matters only if we'd create our own global
operator new/delete, which we don't
- --dynamic-list-cpp-typeinfo affects only the typeinfo (_ZTI*)
and typeinfo name (_ZTS*) symbols, which are not functions, and
so -Bsymbolic-functions shouldn't do anything with them. According
to https://sourceware.org/bugzilla/show_bug.cgi?id=3831
my understanding is that --dynamic-list-cpp-typeinfo actually
predates -Bsymbolic-functions and it was an attempt to do the same
from the other direction ('bind locally everything except for this'
instead of 'bind locally only functions').
Change-Id: Iadad2d78f32a2adfb9c2100fb4eb5abe75725545
Reviewed-on: https://gerrit.libreoffice.org/56739
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Luboš Luňák <l.lunak@collabora.com>
|
|
New languages: Albanian, Galician (by Adrián Chaves),
Norwegian Bokmål and Nynorsk, Ukrainian (based on Russian).
Change-Id: I6b40dfdafe3023edc661b0a9e9f2dedbc94364f8
Reviewed-on: https://gerrit.libreoffice.org/56785
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
autoreconf line doesn't need it, it is the configure one that should
make use of it..
Change-Id: I1d7b492a8d99f8fbcb8443de7a7def2caaf8df3b
Reviewed-on: https://gerrit.libreoffice.org/56745
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Note: this maps to /Z7 apparently:
<DebugInformationFormat>OldStyle</DebugInformationFormat>
https://msdn.microsoft.com/en-us/library/bb629394.aspx
lists various options but passing /p:DebugSymbols=true /p:DebugType=full
/p:PdbFile=... to msbuild.exe by itself doesn't do anything while
patching the project file works.
Change-Id: I888b5f6af7be519e2d35b749873ae7d35bb0bf9d
Reviewed-on: https://gerrit.libreoffice.org/56605
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: I86c7c0f73a21f670676716d7c22f519ed82da145
Reviewed-on: https://gerrit.libreoffice.org/56544
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I8f91e5d00e716bbd0e6aa25697e0b30908ffb8bb
|
|
Change-Id: I3da985f87c5e345ca1c11c54a1f6219bf8a54c70
Reviewed-on: https://gerrit.libreoffice.org/56393
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
The minor version is encoded into the last 2 digits, the micro version
is not avialable.
Change-Id: I4eee40511d732ec8cfc8d85943b965bb6e06d66e
Reviewed-on: https://gerrit.libreoffice.org/56380
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
Change-Id: I70075f4240c75f0f46260bb77b160f0b75d6ae94
Reviewed-on: https://gerrit.libreoffice.org/56354
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
conversion, also other smaller fixes of spelling, suggestion
and morphological analysis using recent Hunspell commits.
Several second or more freezing was occured with Hunspell
dictionaries with compound word handling, because of (1)
combinatorical explosion of overlapping word parts, or
(2) unlimited suggestion algorithms (for example MAP) and
(3) multiple suggestion search for a capitalized,
mixed case or abbreviated long word.
Change-Id: I73e196f907e9b73dcd981d275cedb33878a554f6
Reviewed-on: https://gerrit.libreoffice.org/55965
Tested-by: Jenkins
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
As seen on Linux-rpm_deb-x86@71-TDF:
poppler/Annot.cc:2491:1: internal compiler error: in connect_traces, at dwarf2cfi.c:2676
The bug report claims that -march=i586 works around the bug.
Change-Id: I1d97d2df9049e058d49987424cc8e4818a9fa9c6
|
|
It is provided by the mscng backend.
Change-Id: I1b7e6baf4ba37f7990d1dd685e8d867834e8212d
Reviewed-on: https://gerrit.libreoffice.org/56271
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Change-Id: I43b8eb81b720e83eba887600116b01026e018af9
Reviewed-on: https://gerrit.libreoffice.org/56220
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
On ppc64le with Ubuntu 18.04 and latest LibreOffice from master, the
build fails with the error below.
```
$ uname -m
ppc64le
$ git describe --dirty
libreoffice-6-1-branch-point-897-gd776263a9968
$ git log --oneline -1
d776263a9968 (HEAD -> master, origin/master, origin/HEAD) uitest Calc-Statistics- Descriptive statistics
$ ./configure
[…]
$ make
[…]
checking build system type... ./config.guess: unable to guess system type
This script, last modified 2011-05-11, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
If the version you run (./config.guess) is already up to date, please
send the following data and any information you think might be
pertinent to <config-patches@gnu.org> in order to provide the needed
information to handle your system.
config.guess timestamp = 2011-05-11
uname -m = ppc64le
uname -r = 4.17.0-rc6+
uname -s = Linux
uname -v = #1 SMP Sun May 27 18:16:57 CEST 2018
/usr/bin/uname -p =
/bin/uname -X =
hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch =
/usr/bin/oslevel =
/usr/convex/getsysinfo =
UNAME_MACHINE = ppc64le
UNAME_RELEASE = 4.17.0-rc6+
UNAME_SYSTEM = Linux
UNAME_VERSION = #1 SMP Sun May 27 18:16:57 CEST 2018
configure: error: cannot guess build type; you must specify one
/dev/shm/libreoffice-core/external/libatomic_ops/ExternalProject_libatomic_ops.mk:19: recipe for target '/dev/shm/libreoffice-core/workdir/ExternalProject/libatomic_ops/build' failed
make[1]: *** [/dev/shm/libreoffice-core/workdir/ExternalProject/libatomic_ops/build] Error 1
make[1]: *** Waiting for unfinished jobs....
[…]
```
So, replace the library's config.sub and config.guess by the internal,
more up-to-date copies.
Change-Id: Ib92489943517a4204528f1039f6fba26363b33ee
Solution-by: David Tardon <dtardon@redhat.com>
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-on: https://gerrit.libreoffice.org/56054
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I95e720c9ee5774d87bb4eb8388f8a302ffed8a9b
Reviewed-on: https://gerrit.libreoffice.org/56222
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins
|
|
Unfortunately the autotools build system was removed in 0.60.0, and the
CMake one is a bit overeager in linking against system libraries that
happen to be installed on the build machine, and we currently don't
require CMake anyway, so avoid the problems by using a gbuild makefile
and a patch to add the generated header files.
Remove all current patches:
poppler-notests.patch.1: obsolete (autotools build system)
poppler-mac-fake.patch.1: presumed obsolete
ubsan.patch.0: presumably fixed differently upstream in
https://cgit.freedesktop.org/poppler/poppler/commit/?id=f43cb73939f85952d83afc87a6dc638dc1ae311b
poppler-libjpeg.patch.1: obsolete (autotools build system; there appears
to be no way to do this with CMake?)
0001-Fix-building-with-old-clang.patch.1: merged upstream
Change-Id: I271c87ab3ec25cc9d1e8fafb04dae7c004acc350
Reviewed-on: https://gerrit.libreoffice.org/56166
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Allows dropping the xmlsec1-ecdsa-assert.patch.1 backport.
Also fix the generated test certs + generator script to avoid expired
certs for a while (.db files generated with Firefox 57.0).
Change-Id: I8cba9a01633a3952c845e15e23b18d44544cdb59
Reviewed-on: https://gerrit.libreoffice.org/56123
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I4eab47fd3358d26587e61c9f030f9ed10b067677
Reviewed-on: https://gerrit.libreoffice.org/55783
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: Icced4a3f9a7ad4cbcc908412e577b4dfb85fc6eb
Reviewed-on: https://gerrit.libreoffice.org/55757
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: Idb825a2c96089c53c2734783e0bad02ba3c0f592
Reviewed-on: https://gerrit.libreoffice.org/55755
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I3a61e345593959c47b62ba2da97abafca24ee0e8
Reviewed-on: https://gerrit.libreoffice.org/55754
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I79dde3c8983a70311de2d2a46093fac2722fb372
|
|
Change-Id: I07c6a7c65d5631b70da64927a35d7a3b371eff25
|
|
Change-Id: Id925ba7734a2c73270e40f19d3fc50552441c34e
|
|
Some PDFs don't include spaces in the text.
Instead, they rely on the explicit positioning
of each character to render visually separated words.
Latex seems to be prone to this approach, though not
exclusively.
Luckily, PDFium does process text and inserts
"generated" spaces where necessary, which is what
we retrieve and use as the text string while importing.
Change-Id: Ic21fe6c8416ecaba66f06b6260f1d6b040ff12af
|
|
Change-Id: I7d216ca61b8a10219628877db7dd593a4987ef60
(cherry picked from commit 81f16107c1b0b5315537f38a9830cf967e4abb68)
|
|
Still missing the context matrix transformations.
Change-Id: Id9457c6475463127d3bc444f36fa373a6ec8fcb6
(cherry picked from commit 08e2c68e99151c70d06581261bbc137f80967d9e)
|
|
Change-Id: I01cba9456b37bd7a63c823bbe332d686f7ede389
(cherry picked from commit 26e37f98b08ce59a0feb93a8d2a8fbc982cfc103)
|
|
Change-Id: I5b150721cc1b61b028f282062c1466ef6a67fcae
(cherry picked from commit 37a40d8025ac70f84937de2b1d0f596d08088cbd)
|
|
Change-Id: I9a2fc2c8511655c1aa362c1a03a5e82ae3ba697e
(cherry picked from commit d057cf3d9184cc5d96af9c957411911f5e788f4d)
|
|
Change-Id: I8e63b2a35d841e065ef32fea95c0a5f22ca6f049
(cherry picked from commit 819d11b7ae198a6a8e864852a3654ddbed389ecb)
|
|
Change-Id: Idba294cf5a3a8dd00988f94786715b110039e000
(cherry picked from commit b1083c119832c32d722a4e81415ef7a02c23d4aa)
|
|
Change-Id: I7fa675c6560504e4fc7917e19cac3cceb2700d8e
(cherry picked from commit 3c02b52fdad9c5a34d4bfb7623e04c4e85875a89)
|
|
This makes it trivial to support all sort of
odd bit-format and 8-bit paletted images.
Change-Id: I4555794eccd0ee2906f9a39bd93957ad3775432c
|
|
Change-Id: If37119510cbc091dc86cb5f699984186167745c7
(cherry picked from commit 7dc905d1e9b561bb71f58881190bb6f590d09d80)
|
|
Change-Id: I7c75477f5257931f5182b8d65e898857526bf555
|
|
This was added in commit ebd1b95bb5f9235d1dba1b840fd746c9b53320d2
(INTEGRATION: CWS xmlsec08 (1.1.2); FILE ADDED; 2005-03-10) without any
real commit message to explain why this is necessary.
system-xmlsec (not containing this patch) works fine for our XML signing
purposes with software certificates, and just recently I learned that
even hardware-based certificates work fine without this patch, so it can
go away.
I assume this was a refactor to allow some new feature as a next step,
but that feature was never implemented.
Change-Id: I31639230483cd34b14b35fd41b4fcd8284476138
Reviewed-on: https://gerrit.libreoffice.org/55296
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: Ib920ae6d6a3ced06ffe9f1fc4adba67d95f99a17
Reviewed-on: https://gerrit.libreoffice.org/55207
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Also apply sanitizer.patch, because why not.
Also tweak configure to check for dlsym() instead of dlopen();
the situation described in commit
037584cfe5e58bf6807fb0188d245042baa8c1c0 still holds on Fedora 27.
Change-Id: I446fa3e991aec06452f135ab8365702a397c441a
Reviewed-on: https://gerrit.libreoffice.org/55247
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: Ib294f412055ef23a6ca5608675bc924dacae56f4
Reviewed-on: https://gerrit.libreoffice.org/55248
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
– new Bulgarian and Icelandic language support
– fixes of language data based on libreoffice-l10n's patches
and feedback (see ChangeLog in the external package for details)
Change-Id: I98598747c8b4e8e7fba380998c6ebbc1f63fef2e
Reviewed-on: https://gerrit.libreoffice.org/54936
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
|
|
--enable-ext-mariadb-connector is not the default, this fixes the build
after using that switch up to the mariadb-connector-c module.
mysql-connector-cpp is still broken, VS 2015 gives internal compiler
error there for the used boost pieces...
Change-Id: I1845cde03d5166594aac67c23e61186920ab3785
Reviewed-on: https://gerrit.libreoffice.org/55055
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
As I said in 2ff121f298e64ff204621220622472fe697d599d, passing a
POSIX-style locale name to the std::locale constructor on Windows is
decidedly odd, and apparently boost adds insult to injury by even
really attempting to use a UTF-8 one if that is what our code thinks
it wants. Or something.
This commit avoids the ton of
"warn:unotools.i18n:7996:3544:unotools/source/i18n/resmgr.cxx:123: CRT
Report Hook: ASSERT: f:\dd\vctools\crt\crtw32\stdcpp\xmbtowc.c(89) :
Assertion failed: ploc->_Mbcurmax == 1 || ploc->_Mbcurmax == 2" we
otherwise get when built with --enable-dbgutil and a current VS2015
(or 2017?).
Change-Id: I3a774dff7b12d9960f553c9f242e0463c6d13d5d
Reviewed-on: https://gerrit.libreoffice.org/54444
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
This fixes the following CVEs:
* FTP: shutdown response buffer overflow CVE-2018-1000300
* RTSP: bad headers buffer over-read CVE-2018-1000301
Change-Id: Ic3229577083286501162aa5979a94ce934739557
Reviewed-on: https://gerrit.libreoffice.org/54418
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I581575e2b13482d16aca284bfa502ed164b8c9d0
|
|
Allows dropping the ugly freetype.patch.1.
Change-Id: Ifa8a6dac02a49a2c13572e59773261a847efad3f
Reviewed-on: https://gerrit.libreoffice.org/54294
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Change-Id: Id977be090e09eefcb4196078682694443718c2fd
Reviewed-on: https://gerrit.libreoffice.org/54103
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I55d4b9d29e262138626fc71931088d75f652b8c2
Reviewed-on: https://gerrit.libreoffice.org/53941
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Otherwise, CppunitTest_sw_odfexport (which happens to load both libwps and
libnumbertext) on Linux --enable-dbgutil would cause a crash when
testSpellOutNumberingTypes calls into libnumbertext's use of std::regexp, which
instantiates a std::__detail::_NFA<...> with std::__debug::vector<...> members,
but happens to bind to libwps' (exported, inline) functions to destroy that
_NFA again, and libwps' view of std::__detail::_NFA<...> uses non-debug plain
std::vector<...> members.
(Copy/pastes the code to enable _GBLICXX_DEBUG as already used in various other
external/ExternalProject_*.mk, incl. ExternalProject_libnumbertext.mk. This
mess should be cleaned up.)
(It looks like a libstdc++ bug to me that such instances of _NFA with different
members due to debug mode nevertheless have the same mangled names.)
Change-Id: I92a41a39c5fe6ae5eb71855e32d929690219f1d1
|