summaryrefslogtreecommitdiff
path: root/external/libxml2
AgeCommit message (Collapse)Author
2024-09-18libxml2: upgrade to 2.13.4Xisco Fauli
* 0001-ofz-70675-XML_ERR_FATAL-not-ending-parse.patch.0 is no longer needed. fixed upstream Downloaded from https://download-fallback.gnome.org/sources/libxml2/2.13/libxml2-2.13.4.tar.xz Change-Id: I7d39940ad5b197b302c57110e147aef7d2b911d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173621 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-08-06ofz#70966 use final upstream fixCaolán McNamara
Change-Id: I8423be9fdcd0c224d5d7993a4d982176c404035d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171520 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-08-05ofz#70675 XML_ERR_FATAL not ending parseCaolán McNamara
Change-Id: I3b07ff6e208bf33053540548176a06f28138a6a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171479 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-07-24libxml2: upgrade to 2.13.3Xisco Fauli
it fixes CVE-2024-40896 Downloaded from https://download.gnome.org/sources/libxml2/2.13/libxml2-2.13.3.tar.xz Change-Id: Icba636106cc9d1f096f5479bd80d5e30712c2e6a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/170975 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins
2024-07-01Revert "libxml2: upgrade to 2.13.1"Xisco Fauli
This reverts commit 2b27f0eb5858a4fd296170fb7e4533e5fc7aa3e9. Reason for revert: JunitTest_unordf_complex fails Change-Id: I5c9b6ec454c46a737a7052cc8dd450044dd48495 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169817 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-06-27libxml2: upgrade to 2.13.1Xisco Fauli
Building with --without-system-libxml fails with /usr/bin/ld: /home/xisco/libreoffice/workdir/UnpackedTarball/raptor/src/.libs/libraptor2.so: undefined reference to `xmlNanoHTTPScanProxy' /usr/bin/ld: /home/xisco/libreoffice/workdir/UnpackedTarball/raptor/src/.libs/libraptor2.so: undefined reference to `xmlNanoHTTPClose' /usr/bin/ld: /home/xisco/libreoffice/workdir/UnpackedTarball/raptor/src/.libs/libraptor2.so: undefined reference to `xmlNanoHTTPReturnCode' /usr/bin/ld: /home/xisco/libreoffice/workdir/UnpackedTarball/raptor/src/.libs/libraptor2.so: undefined reference to `xmlNanoHTTPRead' /usr/bin/ld: /home/xisco/libreoffice/workdir/UnpackedTarball/raptor/src/.libs/libraptor2.so: undefined reference to `xmlNanoHTTPCleanup' /usr/bin/ld: /home/xisco/libreoffice/workdir/UnpackedTarball/raptor/src/.libs/libraptor2.so: undefined reference to `xmlNanoHTTPMethod' /usr/bin/ld: /home/xisco/libreoffice/workdir/UnpackedTarball/raptor/src/.libs/libraptor2.so: undefined reference to `xmlNanoHTTPInit' collect2: error: ld returned 1 exit status so use --without-www in external/redland/ExternalProject_raptor.mk since it seems no to be used by raptor. Libxml2 disabled http support by default in https://gitlab.gnome.org/GNOME/libxml2/-/commit/3018842c07e9b88d6bb0257f5644e7695cdeb2e2 Downloaded from https://download.gnome.org/sources/libxml2/2.13/libxml2-2.13.1.tar.xz Kudos to Michael Weghorn for helping me with this patch Change-Id: I2e41021e8aea3551eb9eec29cf12f6cd9f6ff89e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169327 Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp> Tested-by: Jenkins
2024-02-16tdf#159502 libxml2: apply Solaris ld patch only on SolarisMichael Stahl
Diverging from upstream by inventing a LIBXML2_GLOBAL_VARIABLES version should only be done if actually required. Change-Id: I1520ca5078dc24ffd83e927f9c857d625e71749b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163455 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-01-05upgrade libxml2, libxslt & liblangtagCaolán McNamara
what I'm really after is some vexating not-reproducible oss-fuzz msan warnings when using libxml2 in the fodt2pdf fuzzer. So lets upgrade libxml2 to the latest, which requires bumping libxslt, and then requires a newer liblangtag because of no longer implicit includes that it depended on. xmlKeepBlanksDefaultValue and xmlSubstituteEntitiesDefault are deprecated, we should get around to updating those uses Change-Id: I8fda0dffda0a7ea65407d246a3121875cb8ad4a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161598 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-10-31ofz: lots of msan spam in LLVMFuzzerCustomMutatorCaolán McNamara
maybe this is that problem Change-Id: I646a93cf815455f3eb1176df0aac5dd6641de649 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158677 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-05-26external/libxml2: Fix missing external symbols needed by xmllintStephan Bergmann
After 5b42f148e206cda19467e76c2f9915fc2b6fa5f6 "ExternalProject_libxml2 still needs to build the xmllint executable" (which I had happened to prepare on macOS, so didn't originally notice the issue addressed here now), Linux builds like <https://ci.libreoffice.org/job/lo_callgrind_linux/13374/> started to fail with > CCLD xmllint > /opt/rh/devtoolset-11/root/usr/libexec/gcc/x86_64-redhat-linux/11/ld: xmllint-xmllint.o: in function `testSAX': > /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/workdir/UnpackedTarball/libxml2/xmllint.c:1646: undefined reference to `xmlNewSAXParserCtxt' > /opt/rh/devtoolset-11/root/usr/libexec/gcc/x86_64-redhat-linux/11/ld: xmllint-xmllint.o: in function `myReallocFunc': > /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/workdir/UnpackedTarball/libxml2/xmllint.c:357: undefined reference to `xmlMemSize' > collect2: error: ld returned 1 exit status > make[2]: *** [Makefile:1007: xmllint] Error 1 > make[1]: *** [/home/tdf/lode/jenkins/workspace/lo_callgrind_linux/external/libxml2/ExternalProject_libxml2.mk:37: /home/tdf/lode/jenkins/workspace/lo_callgrind_linux/workdir/ExternalProject/libxml2/build] Error 1 Turns out that those two functions have been introduced after the previously used libxml2 2.10.4. No idea how things are supposed to work (given that workdir/UnpackedTarball/libxml2/libxml2.syms starts off with "Retained for backward compatibility. Don't add new symbols.", it appears that there should be some other mechanism at play to make xmllint on Linux find the libxml2.so symbols it needs, but which doesn't work as intended in our build), but just add those two symbols to libxml2.syms for now. (With a new version named LIBXML2_2.11.4, even if the symbols can actually have been introduced in some other version between 2.10.4 and 2.11.4, but who cares.) Change-Id: Ib9d5c7901fe94b8014a87b049fc27ef5658fd954 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152292 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-05-25ExternalProject_libxml2 still needs to build the xmllint executableStephan Bergmann
No idea why fd6cbd983a3021d22321854d0414bdc42c6cb1b7 "upgrade to libxml2-2.11.4" started to only explicitly make libxml2.la (the commit message doesn't say), but that caused at least <https://ci.libreoffice.org/job/lo_ubsan/2788/> to fail with > make[1]: *** Deleting file '/home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/CustomTarget/sfx2/classification/example.validated' > [build VAL] CustomTarget/sfx2/classification/example.validated > /bin/sh: /home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/UnpackedTarball/libxml2//xmllint: No such file or directory > make[1]: *** [/home/tdf/lode/jenkins/workspace/lo_ubsan/sfx2/CustomTarget_classification.mk:20: /home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/CustomTarget/sfx2/classification/example.validated] Error 1 Change-Id: I7e7aa2bae05cf8674720cfd72c78840cd7a28919 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152256 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-05-24upgrade to libxml2-2.11.4Caolán McNamara
'checked' field removed with: https://gitlab.gnome.org/GNOME/libxml2/-/commit/ce76ebfd1312459951d555ad9d87fb9a89eede55 win32 'run_debug' removed with: https://gitlab.gnome.org/GNOME/libxml2/-/commit/59f2f60e3eff07324f1c7cd861a444d714be750b add libxml2-XMLCALL-redefine.patch.0 to avoid: UnpackedTarball\libxml2\include\libxml/xmlexports.h(41): error C2220: the following warning is treated as an error UnpackedTarball\libxml2\include\libxml/xmlexports.h(41): warning C4005: 'XMLCALL': macro redefinition UnpackedTarball\expat\lib\expat_external.h(69): note: see previous definition of 'XMLCALL' Change-Id: Ia9b1540dc1b4eccf91662c8d995c036f71de6fc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/152176 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2022-09-14libxml2: upgrade to release 2.10.2Michael Stahl
Fixes CVE-2022-2309 Change-Id: I180218be275d3b6d38f8f74aa51c57e50d2734ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139911 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-08-08Pass $(verbose) into ExternalProject_libxml2Stephan Bergmann
Change-Id: I11c7c15f4a97d3024a179fd2489fdace27f15216 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137892 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-01try to use also proper debug LDFLAGS for externals librariesLuboš Luňák
This is basically ea68de2968c0dbcd8e7549435e829db06795c16d but for LDFLAGS. A number of external libs cannot use this because their libtool mishandles -fuse-ld. Change-Id: Idee379eb0a3afb475b536519ee3de064b4e218f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133639 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-12use gb_DEBUGINFO_FLAGS consistently in gbuild ExternalProject'sLuboš Luňák
A number of them didn't use it at all, others had it hand-written in various ways. Change-Id: Iaf86325f9cdc032926bac917dc3eef4e34661544 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132818 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-01-31externals: always provide platform configure flagsJan-Marek Glogowski
No idea why we just provided the platform flags when cross- compiling. In the curious case, where the host platform is detected as x86_64-pc-mingw32 per default and we actually want to override it with x86_64-pc-cygwin, we don't do a cross compile, but must override the host platform. But there is additional special handling needed for the omitted cross-platform build in the special case of --host=i686-pc-cygwin and --build=x86_64-pc-cygwin, where we deliberatly ignore cross building; Windows is already a slow build, so try to keep this optimization (AMD64 can execute x86 binaries). There is the theoretical case, where the externals config.guess would have detected something else and that "magically" even worked, while the LO detected triplet would fail, but this should be fixed in the external in any way. Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-03libxml2: use xml2-config dummy for internal buildJan-Marek Glogowski
When building a static LO with --disable-dynloading on Linux, --without-system-libs failed for me. And it left me really puzzled: raptor configure failed and claimed it couldn't link libxml2. raptor's config.log showed missing math functions. xml2-config of LO's build is patched and it includes a -lm. The xml2-config in my chroot doesn't. But we explicitly pass the xml2-config for non-system-libxml2 build. Reading the configure from raptor didn't reveal a way, that it could somehow pick up the xml2-config from the chroot, but that code is autoconf-complex... When running "sh -x configure", it turned out the configure script actually picks up the LIBXML_* flags from the environment, which are set by LO's config_host.mk. These just add -lm for Android. So this adds a xml2-config.in "dummy", which overwrites the one from the libxml2 source and just echos LO's LIBXML_* values and it adds -lm for all DISABLE_DYNLOADING targets. Change-Id: Ia713cf80c8e7dc989cf23c224e7a0f7ea1210a87 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116409 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-08-19augment CFLAGS for libxml2 instead of overwritingCaolán McNamara
so CFLAGS containing msan's -fsanitize=memory are not discarded Change-Id: I3a6cdbe88b1aae37a48e73d5ed7ea06e92d78f6b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120683 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-06-07pass -enable-symbols down to libxmlNoel Grandin
Change-Id: Iceef587366bebe6007f40e100f19e6a2f048adda Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116764 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-05-21libxml2: upgrade to release 2.9.12Michael Stahl
Fixes: CVE-2021-3516 CVE-2021-3517 CVE-2021-3518 CVE-2021-3537 CVE-2021-3541 * external/libxml2/ubsan.patch.0: remove, fixed upstream Change-Id: I347dc854b862e78bde87d3e57cf5fdb584ca5673 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115913 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-05-05WASM: add initial support for Emscripten cross buildJan-Marek Glogowski
- configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2020-05-07no longer force -arch:SSE on WindowsLuboš Luňák
SSE2 has been pretty much a requirement for running Windows since about 2018, so there should be ~nobody needing this. https://lists.freedesktop.org/archives/libreoffice/2020-May/085029.html Change-Id: I579eb92c18e42c57aa1421b889cfa7997b84915f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93558 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-08Optionally generate PDB for libxml.dllJuergen Funk
Change-Id: I58f762fa134052e2a7b4a5c7206b4b75df5c1e69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88156 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2019-11-20libxml2: upgrade to release 2.9.10Michael Stahl
... which is, surprisingly enough, required to build the latest libxslt. Change-Id: Ifbb36ed61b8f68185f9c788f63a8edeb58899f94 Reviewed-on: https://gerrit.libreoffice.org/83311 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2019-10-22external/libxml2: Simplify UBSan nullptr-with-offset fixStephan Bergmann
...that had been added with fcb2d8a87ad696f7f2fe069f0ed68a88803e1b54 "external/libxml2: Avoid UBSan nullptr-with-offset" Change-Id: I7ee234c8c6a868ed825a8ed3fa0dcdc69decb7ba Reviewed-on: https://gerrit.libreoffice.org/81299 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-22external/libxml2: Avoid UBSan nullptr-with-offsetStephan Bergmann
...(new with Clang 10 trunk), where adding even an offset of 0 to a null pointer is UB in C. Seen when building UIConfig_modules/schart: > [UIL] chart2/uiconfig/ui/3dviewdialog > xpath.c:14532:5: runtime error: applying zero offset to null pointer > #0 in xmlXPathTryStreamCompile at workdir/UnpackedTarball/libxml2/xpath.c:14532:5 > #1 in xmlXPathCtxtCompile__internal_alias at workdir/UnpackedTarball/libxml2/xpath.c:14634:12 > #2 in xsltXPathCompileFlags at workdir/UnpackedTarball/libxslt/libxslt/xsltutils.c:2323:11 > #3 in xsltValueOfComp at workdir/UnpackedTarball/libxslt/libxslt/preproc.c:1258:18 > #4 in xsltStylePreCompute at workdir/UnpackedTarball/libxslt/libxslt/preproc.c:2225:6 > #5 in xsltParseTemplateContent at workdir/UnpackedTarball/libxslt/libxslt/xslt.c:4916:13 > #6 in xsltParseStylesheetTemplate at workdir/UnpackedTarball/libxslt/libxslt/xslt.c:5467:5 > #7 in xsltParseStylesheetTop at workdir/UnpackedTarball/libxslt/libxslt/xslt.c:6205:6 > #8 in xsltParseStylesheetProcess at workdir/UnpackedTarball/libxslt/libxslt/xslt.c:6461:2 > #9 in xsltParseStylesheetImportedDoc at workdir/UnpackedTarball/libxslt/libxslt/xslt.c:6675:9 > #10 in xsltParseStylesheetDoc at workdir/UnpackedTarball/libxslt/libxslt/xslt.c:6714:11 > #11 in main at workdir/UnpackedTarball/libxslt/xsltproc/xsltproc.c:888:9 Change-Id: I016ca8d24315385bcfeafca56dda44d9be10f517 Reviewed-on: https://gerrit.libreoffice.org/81285 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-15libxml2: upgrade to release 2.9.9Michael Stahl
* 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>
2018-03-06libxml2: upgrade to release 2.9.8Michael Stahl
Change-Id: Ic6802c16b740f6aee59ae2f74b7edcd37461f1f3 Reviewed-on: https://gerrit.libreoffice.org/50835 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-11-08upload libxml2 2.9.7David Tardon
Change-Id: I3f72ec938c87e0c0d30a91b32d96fedf5379207f Reviewed-on: https://gerrit.libreoffice.org/44423 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2017-11-01external: consistently use gb_ExternalProject_use_nmakeMichael Stahl
... instead of hard-coding some subset of the variables everywhere. Change-Id: I5eac5663563ee9d6cb7b57f5f6e9d55560587276 Reviewed-on: https://gerrit.libreoffice.org/44167 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-10-10upload libxml2 2.9.6David Tardon
Change-Id: Iafb9d9e2459451d213cad5d9141755df999d7ced Reviewed-on: https://gerrit.libreoffice.org/43306 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2017-10-10use gbuild way to update config.*, continuedDavid Tardon
Change-Id: I9abf1742c213f47c576ffbb7dafd33087f7037e5 Reviewed-on: https://gerrit.libreoffice.org/43307 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2017-09-15consistent naming of externals: xml2 -> libxml2Michael Stahl
Change-Id: Ia1164c70d02dce70cb346c1fd4033f12d91c6e5d Reviewed-on: https://gerrit.libreoffice.org/42297 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2017-09-05libxml2: upgrade to release 2.9.5Michael Stahl
* drop ubsan.patch.0: presumably fixed upstream * drop 0001-* CVE fixes: fixed upstream Change-Id: I3e2a53b5ef82ef8edd85e812fd5dee67ab60db94 Reviewed-on: https://gerrit.libreoffice.org/41951 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-08-23libxml2: bunch of CVE fixesMichael Stahl
Change-Id: Ic786fef17cbdb574c342925a4c57875123ef3151
2017-06-11iOS, patch for libxml2jan Iversen
Added support for arm64 Change-Id: Ibd13dc2c56e2caffd97b1f3b78caece2d331b51c
2017-02-10Remove MinGW supportStephan Bergmann
In OOo times, there'd originally been efforts to allow building on Windows with MinGW. Later, in LO times, this has been shifted to an attempt of cross- compiling for Windows on Linux. That attempt can be considered abandoned, and the relevant code rotting. Due to this heritage, there are now three kinds of MinGW-specific code in LO: * Code from the original OOo native Windows effort that is no longer relevant for the LO cross-compilation effort, but has never been removed properly. * Code from the original OOo native Windows effort that is re-purposed for the LO cross-compilation effort. * Code that has been added specifially for the LO cross-compilation effort. All three kinds of code are removed. (An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing --with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.) Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568 Reviewed-on: https://gerrit.libreoffice.org/34127 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2016-12-14libxml2: generate symbols for --enable-dbgutil buildsMike Kaganski
Change-Id: I46df2800eb3440ee6c139867cf00f5cad5c4f3f1 Reviewed-on: https://gerrit.libreoffice.org/32012 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2016-05-24libxml2: upgrade to release 2.9.4Michael Stahl
Change-Id: Ia3109b704155b9baa28f2a5f224e55af161f4fa1 Reviewed-on: https://gerrit.libreoffice.org/25412 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2016-01-23Win build: Set default script engine for cscriptArmin Le Grand
When Windows build is executed, cscript is used to execute JavaScript files. This uses cscript from the system to execute *.js files. cscript is not only capable of executing JavaScript, but also VBScript. Which engine to run is usually determined by the file extension, except when any installed program has added a registered association to the used file type. In that case, the execution of cscript and thus the build fails. This can be prevented by directly defining the script engine when calling cscript, using the /e:javascript parameter for *.js targets. Change-Id: If717b8ae5335acbe4f11c269d3c98a7247a135e6 Reviewed-on: https://gerrit.libreoffice.org/21717 Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de> Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2016-01-19Revert "LTO fixes for android"Tor Lillqvist
Seems to break the tinderbox, needs more work? This reverts commit 6aaf1ec5a781b50ceda6d0d288a43dba435be2ce.
2016-01-18LTO fixes for androidPeter Foley
Change-Id: I2d4cedac4081260c5147d8c11904d042c765e3a6 Reviewed-on: https://gerrit.libreoffice.org/21557 Tested-by: Jenkins <ci@libreoffice.org> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2015-11-21gradle based apk packing doesn't have .so limitation anymoreChristian Lohmaier
and even if it had, everything ends up in liblo-native-code.so now Change-Id: I5d62cf619867d6d0f7c5d4f91acf529706ebdc75
2015-11-20libxml2: upgrade to version 2.9.3Michael Stahl
- drop libxml2-freebsd.patch.1 (upstream libtool 2.4.6 does the same) - drop libxml2-vc15.patch (fixed upstream) Change-Id: Ia2f194f39efebd3d2ea924d23a5543ac53e93116 Reviewed-on: https://gerrit.libreoffice.org/20084 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2015-07-06Libxml2: Fix compilation on VS 2015David Ostrovsky
Change-Id: Ia2bb2897bc3fdb04c89f3328718f32fecd30eb64 Reviewed-on: https://gerrit.libreoffice.org/16760 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2015-01-06external/libxml2: Work around -fsanitize=boundsStephan Bergmann
Change-Id: I57d30410640fa1b7e1768136b1802546b2b7253f
2014-12-03Fold URE: WindowsStephan Bergmann
...assuming the delayLoadHook in cli_ure/source/native/native_bootstrap.cxx is no longer necessary and loading of cppuhelper from the program dir cannot fail regardless in whatever scenario the cli_cppuhelper library itself is loaded. Change-Id: I13f32b327bca4cce9780864f5e57cdad3860afe5
2014-10-02fdo#82430: MSVC build: avoid using SSE2 instructions in some externalsMichael Stahl
Hopefully this should fix up the most important external libraries. Change-Id: I744cb5a2ce7fafb10852059050cf24589d6ca400
generated by cgit (git 2.34.1) at 2025-01-09 00:35:21 +0000