Age | Commit message (Collapse) | Author |
|
Change-Id: I523bc1d848e40489370eefe00046e0a257ed2505
Reviewed-on: https://gerrit.libreoffice.org/27058
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...in preparation of making them orthogonal
Change-Id: If75b334c954138b3aed4f8d1ac33061a2267ad52
Reviewed-on: https://gerrit.libreoffice.org/27056
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The option /Zc:wchar_t- prevented to use wchar_t as a built-in type
according to the C++ standard. In Visual C++ 6.0 and earlier, wchar_t
was not implemented as a built-in type, but was declared in wchar.h as
a typedef for unsigned short. Now, years later after the end of life
this outdated toolchain, there is no reason not to use native type.
The only issue could be the ABI compatibility. But on a quick look at
least, it looks like none of the mangled C++ symbols in the stable URE
interface actually depend on wchar_t.
We forgot to get rid of /Zc:wchar_t- in 5.1. Do that for LibreOffice
5.2, though.
Change-Id: I8d6b380660859efa44c83c830734978d31d756a0
Reviewed-on: https://gerrit.libreoffice.org/22589
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Patch has been upstreamed with
https://ssl.icu-project.org/trac/ticket/12504
Change-Id: I1f3ddad87a2a6568ced3f9d2b2df3e0af0ee18aa
Reviewed-on: https://gerrit.libreoffice.org/24117
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
This does not apply patches
external/icu/khmerbreakengine.patch
external/icu/khmerdict.dict
anymore, as the khmerbreakengine.patch failed to apply with several
hunks of which one was 16k. Asking the patch contributor to follow-up on
this.
Change-Id: I78d4371d04a7b03417d402a222bcd384f02a619e
Reviewed-on: https://gerrit.libreoffice.org/24067
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|
|
Change-Id: I0132196744046391759a6e5110d054feee3deea3
Reviewed-on: https://gerrit.libreoffice.org/23420
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
|
|
Change-Id: I2b776925c2c95cb56ccd592d036823c26054e059
Reviewed-on: https://gerrit.libreoffice.org/23316
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
|
|
Change-Id: Ib897e5fa5e80f75f501694dbf874aabd92253b25
Reviewed-on: https://gerrit.libreoffice.org/21247
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
|
|
Change-Id: Iec71ad4918cd333f0a44d372017ecee300e3aca9
Reviewed-on: https://gerrit.libreoffice.org/20748
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Martin Hosken <martin_hosken@sil.org>
|
|
...for now; workdir/UnpackedTarball/icu/source/tools/toolutil/Makefile invokes
the compiler with a -DU_HOST=\"...\" argument, and apparently directly executes
the compiler from CreateProcess, not going via a shell invocation for the recipe
line. This confuses clang-cl for whatever reason, and for whatever other
reason, forcing make to go via a shell invocation (by adding "true &&" into the
recipe line) fixes it.
Change-Id: I3757a8856f93228c19475b37f3037fa9519a426f
|
|
Change-Id: I8e75b0ab2439592316fc0d871280a438e3ae2f1c
|
|
Change-Id: Iaaa80d997fa7babb9212787653c149b72d842a6c
|
|
Change-Id: Icc3d66c16fca95aa890aee6c67c84674fef878fc
|
|
Change-Id: If5924054b53fd2b5acf2ec903cd1acf710cc2ef1
|
|
See https://wiki.documentfoundation.org/Development/Emscripten for details
Change-Id: I977a8b9e98b9be13c263fef48f567b92347d0492
Reviewed-on: https://gerrit.libreoffice.org/18643
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Change-Id: I1b4f0f3e7f5a7092f904fc8de59bb704073ed7db
|
|
Change-Id: I728177b27fa4049c3f3945246f0f19f937c949b4
Reviewed-on: https://gerrit.libreoffice.org/18216
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Iec2806dfa416bcbfa63eed2985c74c7a2ea897ea
Reviewed-on: https://gerrit.libreoffice.org/16759
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Seems that when cross-compiling to Android from Linux, we apparently
have used either the build platform's pkg-config files for ICU, or the
build platform's icu-config. Both of which are obviously the wrong
thing to do, but apparently it has worked by accident anyway.
This makes building for Android on OS X proceed past harfbuzz, at least.
Change-Id: I27351f6177438697a1cded642c8c669ba7221009
|
|
Change-Id: I15f8e960f253db3f13f68bb2da84f0191d888f5b
|
|
Change-Id: Ib287799906e234ce795a0f9ded5cdeebcdffba4e
|
|
Backported from
http://bugs.icu-project.org/trac/changeset/36724
http://bugs.icu-project.org/trac/changeset/36727
http://bugs.icu-project.org/trac/changeset/36801
Change-Id: Idd85c3344e3ef86e390341038f53ad2a398b3fa3
|
|
Change-Id: Ia972d7364b5acfbafd9df5b07f4fb8bd6efbab5f
|
|
Change-Id: I17936ae2e37520abaa7dd31a5bb9aec6300ea021
|
|
Change-Id: Iad87d17c162717aa33eec2113697422d9b0545ca
|
|
Change-Id: I0ca31fc36b14d433e9276401c952959a46994c91
|
|
Change-Id: Iec76486aa8a0eef7e1a5c74b416d466f16ff979a
|
|
Change-Id: I98d9fecb0f44b0b4354029bab1a5d675e98edd1f
|
|
Change-Id: I4d32ac386ff8b69bee4319e673769917045d9450
Reviewed-on: https://gerrit.libreoffice.org/13547
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I3bd37f8468c95a29ab3385dbc3ae825b76d8d3df
|
|
Change-Id: I9325bb28eb267b023f628e24fea216ad580759e9
|
|
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).
Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
|
|
Change-Id: I8f0db23d1f9ba6b9fc3c8b64b32822ba8166428f
|
|
Change-Id: I7d8e3be80f04ec0a9d1dbd394ac0e2ab2f1a4551
|
|
Change-Id: I44b5d74a3c1addaec77e724a3e7356e3648fc10c
|
|
Change-Id: Ie83e3104bd639be42ac0c6e25fc2eafd88cf0c6f
|
|
Hopefully this should fix up the most important external libraries.
Change-Id: I744cb5a2ce7fafb10852059050cf24589d6ca400
|
|
Change-Id: Iaa62d8438012e32167c9179da29c446850cf1deb
|
|
Change-Id: I67d0b4b0c39c62646c7a0ae7152c7ca256680c38
|
|
Change-Id: I3787a46cf8662ed709534db85d724c17c21b90dd
|
|
Change-Id: Ia33eb3e4c89963d7391df0339a2a5b948efd0d9f
|
|
Change-Id: I0c052cbcfe375bd1279c2235b53c909920e2e779
|
|
Change-Id: I5dd63fa41c1568e8bf2d120cc0de5d2c44dd789c
|
|
Linking libxml2 against ICU libraries has a nasty side effect:
The URE library javavm.dll links against URE libxml2.dll, which
is now linked against OOO icuuc53.dll; when a URE program, like
uno.exe, tries to load javavm.dll it fails because the OOO layer
"program" dir is not on PATH; this breaks the installation of Java
extensions.
Fix that by splitting up ICU libraries and putting the required ones
into URE layer.
(regression from 7515b1a90fac9e31733c0fdcc1156adadf0e6f99)
Change-Id: If98dd0357162cb632d9762cd2d20162de5eb1a52
|
|
No idea why this wasn't a problem before.
Change-Id: Icbb94111061079069e2fc2102cfa4fe4bdd59bb9
|
|
Change-Id: I22485919713f5cafb494992a36c5ada21bdcc18c
|
|
...so that -fsanitize=undefined does not report false out-of-bounds accesses;
Clang's isFlexibleArrayMemberExpr (lib/CodeGen/CGExpr.cpp) only treats arrays of
length 0 and 1 as such special flexible cases.
There appears to be no code in icu that depends on those arrays to be of length
2 (e.g., via sizeof), though it does look suspicious that they are deliberately
of length 2 instead of 1.
Change-Id: I85293e769f1d64cb4e60e13f1cd7f88b76e37487
|
|
Change-Id: I41ec24a02867ba3c5bf4f39b5d79bf6a3254ad0d
|
|
ICU now has its (U_PLATFORM == U_PF_ANDROID) directive.
Change-Id: If740ea0c8004a2a8365d46b5ecf0e388b5965f62
|
|
plus further work in i18npool to make that build
adapt i18npool to ICU 53 upgrade, fdo#77071
Korean charset collator can't be built from ko_charset.txt because of
"The runtime code decomposes Hangul syllables on the fly, with recursive
processing but without making the Jamo pieces visible for matching. It
does not work with certain types of contextual mappings."
"While handling a Hangul syllable, contractions starting with Jamo L or
V would not see the following Jamo of that syllable." (this is where we
bail out already with the first syllable of ko_charset.txt)
Another condition to fail is described as "A contraction ending with
Jamo L or L+V would require generating Hangul syllables in
addTailComposites() (588 for a Jamo L), or decomposing a following
Hangul syllable on the fly, during contraction matching."
Excluded the file from the build for ICU >=53 and hope that ICU in the
mean time handles Korean collation correctly.
Additionally, ICU 53 took ages (if it would had finished at all) to
build the collator from zh_TW_charset.txt because of the \u#### escaped
notation. Converted the file's content to characters using
http://www.rishida.net/tools/conversion/
Change-Id: I64213214b4870e7077f72b95fee1ddc9782c2b21
Reviewed-on: https://gerrit.libreoffice.org/9204
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
|