Age | Commit message (Collapse) | Author |
|
Support for arm64
Change-Id: Ibba1a9486b8eaee4bf3c0cf673dd4cc112d084e0
|
|
Added support for arm64
Change-Id: Ie48a463b0f0a8af98001fed592d59a8e7b0d0225
|
|
Added support for arm64, by modifying the
patch that reverts an earlier commit.
Change-Id: If0d1920c1a91b3ad44c4ae9c299270b7806db811
|
|
changed --with-libcoretext
from "yes" to "auto" for IOS and MACOSX
Change-Id: I032ad9975413709fdfaead745b63e04f0e0db27e
|
|
Support for arm64
Change-Id: Ie2289e4df9f90b7c31357ecfe859f087a7df9c5a
|
|
Support for arm64
Change-Id: I1f5d8a11f42026b08aa01a8a19059c18ff116c1c
|
|
Change-Id: Ib2ba32d48d3df16b0b20deea84416fe15a2d7176
Reviewed-on: https://gerrit.libreoffice.org/38650
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
Add support for arm64
Change-Id: Icfc47b0c3b600ea3d26c40741c933028e8e9c47d
|
|
Patch was added in wrong sequence.
Change-Id: I4d700d0f9591dbb43c738ef69f823488b9c3162c
|
|
support for arm64, in submodules as well
Change-Id: Idc13b03d2fcc9bcf11fe4dadc0fc298a9871848f
|
|
support for arm64
Change-Id: I4e92c55253fba95944972401bbb948caf1ea903e
|
|
add support for arm64
Change-Id: I76dc00058abd27b8e022ffcd0d68ff00446ebeb6
|
|
Support for arm64
Change-Id: Iedac1ee7d1b2ba7976ae56fdf24dd66d99f16264
|
|
Added support for arm64
Change-Id: Ibd13dc2c56e2caffd97b1f3b78caece2d331b51c
|
|
Added patch to support arm64
Change-Id: Ie5d9ea3f3bed6e8f3142f0209a0068bb698a3960
|
|
Patch allowing cputype arm64
Change-Id: Idca7d40a4186cd724599af8b4b9891f9f876aa31
|
|
Added support for arm64 in the icu4c configuration
(done in form of a patch to the original)
Change-Id: I96508c29261531a24ae946b247b18c55d6259f51
|
|
Change-Id: Icd0526c0bf0183b80bc4c098e3307574b8b8bb8b
Reviewed-on: https://gerrit.libreoffice.org/38592
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
...that was recently introduced into Clang trunk with
<https://reviews.llvm.org/D33305> "[ubsan] Add a check for pointer overflow UB".
Here, _code is of type instr*, dist is of type ptrdiff_t, and sizeof(instr) is
something like 8. My first impulse was to cast the result of the division (done
with arguments promoted to size_t) back to ptrdiff_t, but that wouldn't help:
When dist is a relatively small negative number (like
-3293184), the division expression will promote it to a large unsigned (size_t)
value (like 0xFFFF'FFFF'FFCD'C000), but the result (in our case,
0x1FFF'FFFF'FFF9'B800) would be small enough to fit into ptrdiff_t as a positive
value. So assume that sizeof(instr) fits into int and ensure the division is
done on signed values.
(At least CppunitTest_sc_subsequent_filters_test started to fail with
"workdir/UnpackedTarball/graphite/src/inc/Code.h:165:15: runtime error: pointer
index expression with base 0x7fb90a3b4df0 overflowed to 0x7fb90a0a0df0".)
Change-Id: Ie6698e38d6abec80f2fa817c42ebf20618496109
|
|
...in favor of gb_LinkTarget_add_generated_exception_objects. The former would
have needed any flags to be passed in explicitly (but no call sites did), so
e.g. StaticLibrary_graphite didn't have any debug information (when building
with --enable-debug). I guess there is no downside to having C++ exception
support enabled in these places, and using _add_generated_cxxobjects instead was
likely an oversight in the first place (at least in the case of
external/graphite/StaticLibrary_graphite.mk, it was that way ever since
1ceb47d96da9e7977c96241f49ad291ff0466970 "graphite: convert to gbuild", but for
no apparent reason).
Change-Id: I9986a6c5ec30a521095dbe5315e5ca649741a790
|
|
In 64-bit builds the 64-bit runtimes are installed as MSM so this hack
isn't needed there.
Change-Id: Id609d2beaa3de1176138bc206210820397a8b732
|
|
Change-Id: I1b862ed2d69c41361bc8c26d96c5329473fe64aa
|
|
Change-Id: I485b725ff824f113991900c1ea110aab1b0421af
|
|
Before the gbuild conversion in commit
ec6af4194e80f5f0b2e46ca59802ff397a2a4a24 (convert libxmlsec to gbuild,
2012-11-29) the makefile.mk had a comment for this patch: "Disable use
of smime3 so don't need to package it".
Today smime3 is packaged (see external/nss/ExternalPackage_nss.mk), so
patching xmlsec is no longer needed.
Change-Id: I73ec13ee92a1860f5dc3cbeed0e51d42a0320baa
Reviewed-on: https://gerrit.libreoffice.org/38239
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I4d32b7c4b2e545a8d979bc516f64cfcbf66ecd07
|
|
...and python-3.3.0-msvc2012.patch etc.
They were actually never applied to Python 3.5.
Change-Id: I5beb5a81d55ab1921411d2351bdb397ff02ba75c
|
|
Change-Id: I6e80c33d134100235ac1007154ca7f6151b59c2f
|
|
Change-Id: I044be3b53134081bcbdbfd6fd252d6851d3dba41
|
|
Change-Id: I329289c97b857370852c982a8b74b739b9ac3d78
|
|
Change-Id: Ifef3e75065e55aefba0f9498cf517efaf78ba6c1
|
|
Change-Id: I19b7d324a2dc50d006b4d255ddb6a5c1f15bc616
Reviewed-on: https://gerrit.libreoffice.org/37998
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
These flags are new in xmlsec-1.2.24.
Change-Id: If32faa6e1d3a5f51fa4d631973d8bd0962783a34
Reviewed-on: https://gerrit.libreoffice.org/38004
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Change-Id: I67932541fbb14316798fe94b64b4b32a3d1c29f6
Reviewed-on: https://gerrit.libreoffice.org/37984
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
This allows dropping the now upstreamed system-zlib.patch.1.
Change-Id: I92668ff243fa7f14a418cec419c003d4a9bc96ce
Reviewed-on: https://gerrit.libreoffice.org/37960
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
...otherwise ASan build started to fail in CppunitTest_services with
> ==16664==ERROR: AddressSanitizer: odr-violation (0x7f4583587440):
> [1] size=35 'xmlSecNs' strings.c:22:15
> [2] size=35 'xmlSecNs' strings.c:22:15
> These globals were registered at these points:
> [1]:
> #0 0x44f410 in __asan_register_globals.part.11 /data/sbergman/github.com/llvm-project/llvm-project-20170507/compiler-rt/lib/asan/asan_globals.cc:358
> #1 0x7f458295cded in asan.module_ctor (instdir/program/libxsec_gpg.so+0x197ded)
>
> [2]:
> #0 0x44f410 in __asan_register_globals.part.11 /data/sbergman/github.com/llvm-project/llvm-project-20170507/compiler-rt/lib/asan/asan_globals.cc:358
> #1 0x7f45833cc28d in asan.module_ctor (instdir/program/libxsec_xmlsec.so+0x5da28d)
>
> ==16664==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
> SUMMARY: AddressSanitizer: odr-violation: global 'xmlSecNs' at strings.c:22:15
> ==16664==ABORTING
after cae5f2a543b31552ccd9765aca5eb514fa694e07 "gpg4libre: initial GPG signature
generation"
Change-Id: I689241df52a7e878bfbd2d3dd6409bf0c104638b
|
|
This flag does exactly what we need since xmlsec-1.2.24.
Change-Id: I3ae052d4bfe564c3234aef2511ef82ebdb452ebe
Reviewed-on: https://gerrit.libreoffice.org/37700
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
|
|
Upstream changes interesting for us:
- Added ECDSA-SHA1, ECDSA-SHA256, ECDSA-SHA512 support for xmlsec-nss,
so we can drop 2 patches
- Fixed XMLSEC_KEYINFO_FLAGS_X509DATA_DONT_VERIFY_CERTS handling, which
allows dropping xmlsec1-noverify.patch.1 in the future
Also backport a patch from xmlsec master that fixes signature creation
on Windows (the release regressed in this regard).
Change-Id: I2c14328283bf7d4f8af5595ea4c1efc29ee81f9e
|
|
> [build CXX] workdir/UnpackedTarball/boost/libs/locale/src/shared/date_time.cpp
[...]
> In file included from C:/lo64/core/workdir/UnpackedTarball/boost/libs/locale/src/shared/date_time.cpp:11:
> In file included from C:/lo64/core/workdir/UnpackedTarball/boost\boost/thread/mutex.hpp:14:
> In file included from C:/lo64/core/workdir/UnpackedTarball/boost\boost/thread/win32/mutex.hpp:9:
> In file included from C:/lo64/core/workdir/UnpackedTarball/boost\boost/thread/win32/basic_timed_mutex.hpp:14:
> C:/lo64/core/workdir/UnpackedTarball/boost\boost/thread/win32/thread_primitives.hpp(172,55): error: conflicting types for 'CreateMutexA'
> __declspec(dllimport) void* __stdcall CreateMutexA(_SECURITY_ATTRIBUTES*,int,char const*);
> ^
> C:/PROGRA~2/WI3CF2~1/10/Include/10.0.15063.0/um\synchapi.h(489,1): note: previous declaration is here
> CreateMutexA(
> ^
[...]
Change-Id: I141ea196250dc855c780f237436c0f19f0594cb1
|
|
This was added in commit ebd1b95bb5f9235d1dba1b840fd746c9b53320d2
(INTEGRATION: CWS xmlsec08 (1.1.2); FILE ADDED, 2005-03-10). According
to CWS history it was introduced in the 1.1.2.1 part, without any
further comments.
Before the gbuild conversion in commit
ec6af4194e80f5f0b2e46ca59802ff397a2a4a24 (convert libxmlsec to gbuild,
2012-11-29) the makefile.mk had a comment for this patch: "Dubious, do
we still need this ?".
My best guess is that this was added as part of some effort to do ODF
encryption (not just signing) in xmlsecurity, but code for that on the
xmlsecurity part is already removed.
Change-Id: I3a5f1fedd7ce10b8b874bb8a3c9e6260213fbd8f
Reviewed-on: https://gerrit.libreoffice.org/37261
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
...as needed e.g. for <https://bugs.llvm.org/show_bug.cgi?id=32349> "r294897 +
NewGVN cause build failure with LibreOffice", by applying
<http://git.savannah.gnu.org/cgit/libtool.git/commit/
?id=d9a35fe9d3508b5c0d56e7f2ec80fc05e8415fa3> "libtool: Discard '-mllvm $arg'
options when linking."
Change-Id: Id2afc3c8af3c6c9595e7cb33cef5084a74f78cb0
|
|
...since <http://llvm.org/viewvc/llvm-project?view=revision&revision=301647>
"Use the -Wunknown-warning-option group for the 'unknown warning group'
diagnostic in #pragma diagnostic".
* external/boost/include/boost/{locale.hpp,locale/gnu_gettext.hpp} would have
been removed by 'make cmd cmd=bin/gen-boost-headers' as they are still unused
from c25eee44966703cb27d632bccb39b20978341ffd "build boost::locale library",
but there's reportedly a patch in Gerrit to actually use them, so I fixed them
manually for now.
* The deviating comment style is to keep lines no wider than 80 characters.
Change-Id: I64603ae8d8a82781eda46f12c9dd5c68dcf395b9
|
|
Change-Id: I14782971dd35f8d96f1e9b08fdf060aa917a1e37
|
|
Change-Id: I40b89a0df483645fc743fb092d3d39ea682c510c
Reviewed-on: https://gerrit.libreoffice.org/37060
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
https://ssl.icu-project.org/trac/ticket/13176
Change-Id: I1bf7a0787f46186895e7ee9144d5f219ea59e2df
|
|
https://ssl.icu-project.org/trac/ticket/13175
Change-Id: Ib7756f3c41d2395f65d898e39808616c04ee58ee
|
|
... instead of the entire icu4c-59_1-data.zip content.
Change-Id: Icfbf7d4103059f525b303b194212b78935fb00b1
Reviewed-on: https://gerrit.libreoffice.org/37001
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
Also regenerated all patches using make icu.genpatch (hence the .1
suffix that indicates the path level) as some hunks did not apply anyway
and all now have the correct offset. Using genpatch may have the future
benefit to yield smaller diffs between different versions of patches.
Also prefixed all patch names with icu4c- for a cleaner listing.
New patches introduced are prefixed with icu4c-59-...
Change-Id: Ia83754b0823839887fce1a1d4ed04f8375b113c2
Reviewed-on: https://gerrit.libreoffice.org/36809
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
This contains the new FPDFPath_GetFillColor / FPDFPageObj_GetType APIs I
want to use in CppunitTest_vcl_pdfexport.
Change-Id: I275ff761188c07dbbab27a1e0715ac250cd306c9
Reviewed-on: https://gerrit.libreoffice.org/36974
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
|
|
Looks like neither the __GNUC__ specific __attribute__((constructor)) definition
of CONSTRUCT nor the _MSC_VER specific one (if the #ifs were reordered so that
clang-cl would pick the latter) with __declspec(allocate(".CRT$XCU")) are
supported by clang-cl, and both are rather silently ignored. That means that
library_init is not called, library_initialized remains false, and the first
call to get_dlopen_handle aborts.
But this whole "verify that get_dlopen_handle isn't called too early" business
is somewhat pointless here (and that's the only use of the CONSTRUCT macro, and
DESTRUCT isn't used at all), so just short-circuit it for clang-cl for now.
Change-Id: I5d50df3574d350f9591e807ef0fb6a1b02dc34ec
|
|
Uwinapi is discontinued.
Change-Id: I063b4d0d8fab2d60de168e960a63b8181158ac01
Reviewed-on: https://gerrit.libreoffice.org/23198
Reviewed-by: David Ostrovsky <david@ostrovsky.org>
Tested-by: David Ostrovsky <david@ostrovsky.org>
|