summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)Author
2022-05-03use proper MSVC runtime lib for libwebpLuboš Luňák
Change-Id: Icf976bb4a4593bfa8e8fc506d4c5e86cb7f88671 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133705 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-05-01improve support for using libc++ on Linux and for libc++ debug modeLuboš Luňák
It seems to run slightly faster in --enable-dbgutil mode and also builds a bit faster (at least with Clang). But libc++ on Mac isn't built with debug mode support. Change-Id: Idf5dba9c4a56aba1f4163aa518a78d34b6837149 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133664 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.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-26ofz: Use-of-uninitialized-valueCaolán McNamara
the msan flags aren't getting passed in Change-Id: Ib79c63cf559be9b11e19e2f8b11fd56b44665c93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133420 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-04-26Drop unused LanguageTool extensionGabor Kelemen
Do not bundle LanguageTool which is at a 10 year old version (1.7) while upstream has a lot of new releases (now at version 5.5.x) It is not bundled by any downstream distributions so it makes no much sense to keep it integrated here. Change-Id: Icd2ef151b1b8d0252ffa3db0caaba576f2783fa9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133356 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2022-04-26Drop unused CT2N extensionGabor Kelemen
It is not bundled by any downstream distributions so it makes no much sense to keep it integrated here. Change-Id: I80180e53e050b8b3cd1b173ef01b51e8d706f295 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133355 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2022-04-25external/firebird: Missing include in configure checkStephan Bergmann
...so that with Clang 15 trunk after <https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626> "[C11/C2x] Change the behavior of the implicit function declaration warning" the check now failed to compile with > configure:21471: checking alignment of long [...] > conftest.c:177:3: error: call to undeclared library function 'exit' with type 'void (int) __attribute__((noreturn))'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > exit((int)&((struct s*)1024)->b - 1024); > ^ > conftest.c:177:3: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit' and an exit code of 1 from the compiler invocation, which the check than silently mistook as an alignment requirement of 1. (Which then caused the somewhat obscure fallout of > workdir/UnpackedTarball/firebird/src/gpre/msc.cpp:463:10: runtime error: member access within misaligned address 0x7f59d8e68196 for type 'gpre_sym', which requires 8 byte alignment while building ExternalProject_firebird with UBSan.) The corresponding "checking alignment of double" a few lines further down had already been modified in ccd0e5f445d4a7d0e7aca6c23c02c61bf14510b2 "Make firebird build for macOS on arm64", but without stating what actual problem (if any) it fixed. I thus moved that patch into the new external/firebird/configure-include.patch too, to have them grouped together. (An alternative fix could be to replace the use of exit with return from main in those configure checks.) Change-Id: Iefa02a06d45c83add5f56fad5d726aaecee6d815 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133368 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-25external/openldap: Don't use pthread_get/setconcurrency without declarationsStephan Bergmann
At least with glibc on Linux, those two functions are only declared in <pthread.h> when _XOPEN_SOURCE is defined. And with <https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626> "[C11/C2x] Change the behavior of the implicit function declaration warning" in Clang 15 trunk that now causes hard errors > thr_posix.c:93:9: error: call to undeclared function 'pthread_setconcurrency'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > return pthread_setconcurrency( n ); > ^ > thr_posix.c:107:9: error: call to undeclared function 'pthread_getconcurrency'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > return pthread_getconcurrency(); > ^ (vs. just silently ignored warnings) when building ExternalProject_openldap. (And the way the corresponding AC_CHECK_FUNCS in workdir/UnpackedTarball/openldap/configure.in works, it always set HAVE_PTHREAD_GET/SETCONCURRENCY because it effectively checks for availability of the symbols in a library, not for declarations of the C functions in an include file.) But if we explicitly define _XOPEN_SOURCE, we now also need to explicitly define _DEFAULT_SOURCE or _BSD_SOURCE (which is otherwise implicitly defined by default in glibc's features.h if no other such macros are defined). Change-Id: I148d50c82ee2efc2a54f2cf4f84dead3941a3568 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133312 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-22external/libassuan: Fix fallout of defining __STDC__ on WindowsStephan Bergmann
...since 1bb0e177124d5d6661b72df6c7d848fb23639652 "Fix autoconf>=2.70 gcc-wrapper breakage", which had the side effect of preventing various deprecated function declarations in system headers (e.g., isascii in addition to __isascii). This went unnoticed so far due to the traditionally lax handling of missing function declarations in C, and only now started to cause > conversion.c(94,9): error: call to undeclared function 'isascii'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > if ((isascii (*istr) && isprint (*istr)) || (*istr >= 0x80)) > ^ etc. with clang-cl 15 trunk after <https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626> "[C11/C2x] Change the behavior of the implicit function declaration warning". Where undeclared functions have been used in Windows-only code, they have been replaced with their __STDC__-declared counterparts, and for occurrences in shared code Windows-only macro definitions have been introduced (as would have done in the system headers too, if __STDC__ was not defined) to not clutter the shared code with #ifdefs. Also, for getpid (resp. _getpid), the #include <process.h> was apparently missing from the upstream code, even without our __STDC__ hack in external/libassuan/ExternalProject_libassuan.mk (but never caused errors until now, either). Change-Id: I7442394d0c6e633bca1f6c7331d7ee51651179a4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133339 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-22external/gpgmepp: Missing includes (Windows)Stephan Bergmann
> gpgme-w32spawn.c(288,8): error: call to undeclared function 'open'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > fd = open (trans_file, O_RDONLY); > ^ etc. with clang-cl 15 trunk after <https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626> "[C11/C2x] Change the behavior of the implicit function declaration warning", which went unnoticed so far due to the traditionally lax handling of missing function declarations in C. Change-Id: I805ab10d2b0aae3f8b1f46ffeda57aff2bbcef2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133340 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-22external/libgpg-error: Missing include (getpid, Windows)Stephan Bergmann
This was apparently missing from d400009e7c74d13f01fda923d7399eac11b83b66 "gpg4libre: update gpgme, libassuan and libgpg-error" but went unnoticed so far due to the traditionally lax handling of missing function declarations in C, and only now started to cause > logging.c(845,57): error: call to undeclared function 'getpid'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration] > (unsigned int)getpid (), pidsuf); > ^ with clang-cl 15 trunk after <https://github.com/llvm/llvm-project/commit/7d644e1215b376ec5e915df9ea2eeb56e2d94626> "[C11/C2x] Change the behavior of the implicit function declaration warning". Change-Id: I66dc409f629d9bda807bc9cca21a8a5ecdda79be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133338 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-20android: Use property instead of ANDROID_NDK_HOME env varMichael Weghorn
Write an `ndk.dir` property with the directory path to `android/source/local.properties` instead, similar to how it's done for `sdk.dir`. Also, rename the `ANDROID_NDK_HOME` variable that's assigned in configure.ac that holds the corresponding value to `ANDROID_NDK_DIR`, because the gradle warning still shows up if that environment variable is set in addition to having an `ndk.dir` property in `local.properties`. This makes the following gradle warning disappear: > > Task :stripStrippedUIDebugDebugSymbols > WARNING: Support for ANDROID_NDK_HOME is deprecated and will be removed in the future. Use android.ndkVersion in build.gradle instead. > Support for ANDROID_NDK_HOME is deprecated and will be removed in the future. Use android.ndkVersion in build.gradle instead. Note however, that with this approach of using the `ndk.dir` property instead of the suggested `android.ndkVersion` (with the latter having the stricter requirement that the `ndk` dir would have to be a subdir of the SDK dir), doing the actual upgrade to a newer Gradle (plugin) version in follow-up commit Change-Id Ia982d72d877e229c3006c6d528b830d16c88481f "android: Update Android Gradle Plugin to 7.1.3" revealed that the use of the `ndk.dir` property is deprecated in newer Gradle (plugin) versions as well, resulting in this warning. > > Task :stripStrippedUIDebugDebugSymbols > [CXX5106] NDK was located by using ndk.dir property. This method is > deprecated and will be removed in a future release. Please delete > ndk.dir from local.properties and set android.ndkVersion to > [20.0.5594570] in all native modules in the project. > https://developer.android.com/r/studio-ui/ndk-dir It might make sense to address that in a follow-up step, but for now, it's an improvement and keeps it working after the upgrade without potentially causing any incompatibility problems with existing autogen configurations, while support for the `ANDROID_NDK_HOME` env var that was used so far seems to have been dropped, resulting in > > Task :stripStrippedUIDebugDebugSymbols > Unable to strip the following libraries, packaging them as they are: > libc++_shared.so, libfreebl3.so, liblo-native-code.so, libnspr4.so, > libnss3.so, libnssckbi.so, libnssdbm3.so, libnssutil3.so, > libplc4.so, libplds4.so, libsmime3.so, libsoftokn3.so, > libsqlite3.so, libssl3.so. instead if upgrading gradle without switching to the use of the property. Change-Id: I4a090e8736dac80777f69b0e12819b9c056f582b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133177 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
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-04-12libwebp is a C library, set CFLAGS and not CXXFLAGSLuboš Luňák
Change-Id: I79da4dcc61f50634dc8812dc5bf382053c170a9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132817 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-07work around ICU performance problem in text breaking (tdf#116400)Luboš Luňák
Reported upstream at https://unicode-org.atlassian.net/browse/ICU-21946 , they've confirmed the problem, but so far no actual code change. So let's push my patch for now. Change-Id: Idd92ca66eea9b28103ad890aec66c40029ec7ebd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132676 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-07nss: depend on zlibMichael Stahl
Required on WNT since 1c748fefc3c5b42e3548a1a7f5017a579982005a, may be needed on other platforms if using --without-system-zlib. Change-Id: Ib8e544d81881f425d257514fc475e272ca2e53ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132648 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Tested-by: Jenkins
2022-04-06Remove obsolete HSQLDB_USE_JDBC_4_1Stephan Bergmann
...that must always be true ever since 1b8c61d5ca8e2a7ae7a0bcd189b7a87defecea03 "Bump JDK buildtime requirement to 1.6" Change-Id: I9432ac9d0a0e2c4999a80b6f144099d0e4dc15bc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132616 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-04-05Allow building against JDK 18Stephan Bergmann
...where ExternalProject_hsqldb failed with > [java] java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:194) > [java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:891) > [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:231) > [java] at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:135) > [java] at org.apache.tools.ant.taskdefs.Java.execute(Java.java:108) > [java] at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:299) > [java] at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > [java] at java.base/java.lang.reflect.Method.invoke(Method.java:577) > [java] at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:99) > [java] at org.apache.tools.ant.Task.perform(Task.java:350) > [java] at org.apache.tools.ant.Target.execute(Target.java:449) > [java] at org.apache.tools.ant.Target.performTasks(Target.java:470) > [java] at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401) > [java] at org.apache.tools.ant.Project.executeTarget(Project.java:1374) > [java] at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) > [java] at org.apache.tools.ant.Project.executeTargets(Project.java:1264) > [java] at org.apache.tools.ant.Main.runBuild(Main.java:818) > [java] at org.apache.tools.ant.Main.startAnt(Main.java:223) > [java] at org.apache.tools.ant.launch.Launcher.run(Launcher.java:284) > [java] at org.apache.tools.ant.launch.Launcher.main(Launcher.java:101) > [java] Caused by: java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release > [java] at java.base/java.lang.System.setSecurityManager(System.java:416) > [java] at org.apache.tools.ant.types.Permissions.setSecurityManager(Permissions.java:103) > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:216) > [java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:155) > [java] ... 19 more while building target switchtojdk17 (but then unfortunately carried on, without the source modifications that should have been done by that target, leading to confusing errors like > [javac] workdir/UnpackedTarball/hsqldb/src/org/hsqldb/jdbc/jdbcConnection.java:426: error: jdbcConnection is not abstract and does not override abstract method createStruct(String,Object[]) in Connection that should have been under control at least ever since 7dbfc0012cc75e7dac9a416b53149ad8ec33f071 "make hsqldb build with java 1.7".) Unconditionally passing ANT_OPTS -Djava.security.manager=allow would cause older JDK versions (like Java 11) to fail with a java.lang.Error "Could not create SecurityManager" caused by a java.lang.ClassNotFoundException "allow", so introduce JDK_SECURITYMANAGER_DISALLOWED_FOR_BUILD. This should allow us to keep building against at least JDK 18, even though later versions of Java may remove the Security Manager completely, but in which case hopefully an updated version of Apache Ant will become available. Change-Id: I9d143d8bcfff67870017bb1c874eec53e0ff9672 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132558 Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2022-04-01nss: build with zlib module on WNTMichael Stahl
Change-Id: Ie875b4a8df1697de83a8f22cb1170a49792c47e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132367 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-03-31zlib: upgrade to release 1.2.12Michael Stahl
Fixes CVE-2018-25032 external/zlib/ubsan.patch: remove, fixed upstream Change-Id: I2aa9a9008b9cf7efd970c5fff0df7029204204f8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132358 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-03-31external/freetype: Avoid nullptr-with-offsetStephan Bergmann
> workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:967:17: runtime error: applying zero offset to null pointer > #0 in ft_var_get_item_delta at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:967:17 > #1 in tt_hvadvance_adjust at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1138:13 > #2 in tt_hadvance_adjust at workdir/UnpackedTarball/freetype/src/truetype/ttgxvar.c:1162:12 > #3 in tt_face_get_metrics at workdir/UnpackedTarball/freetype/src/sfnt/ttmtx.c:326:11 > #4 in TT_Get_HMetrics at workdir/UnpackedTarball/freetype/src/truetype/ttgload.c:104:5 > #5 in tt_get_advances at workdir/UnpackedTarball/freetype/src/truetype/ttdriver.c:269:9 > #6 in FT_Get_Advance at workdir/UnpackedTarball/freetype/src/base/ftadvanc.c:97:15 > #7 in af_shaper_get_elem at workdir/UnpackedTarball/freetype/src/autofit/afshaper.c:673:7 > #8 in af_latin_metrics_check_digits at workdir/UnpackedTarball/freetype/src/autofit/aflatin.c:1105:21 > #9 in af_latin_metrics_init at workdir/UnpackedTarball/freetype/src/autofit/aflatin.c:1156:7 > #10 in af_face_globals_get_metrics at workdir/UnpackedTarball/freetype/src/autofit/afglobal.c:462:17 > #11 in af_loader_load_glyph at workdir/UnpackedTarball/freetype/src/autofit/afloader.c:306:13 > #12 in af_autofitter_load_glyph at workdir/UnpackedTarball/freetype/src/autofit/afmodule.c:489:13 > #13 in FT_Load_Glyph at workdir/UnpackedTarball/freetype/src/base/ftobjs.c:978:19 > #14 in FreetypeFont::GetGlyphOutline(unsigned short, basegfx::B2DPolyPolygon&, bool) const at vcl/unx/generic/glyphs/freetype_glyphcache.cxx:903:19 [...] during CppunitTest_svx_unit Change-Id: I6d45ec44006458350629edf06b8ec092a450ea05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132357 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-03-30forcepoint#95 read past end of malformed documentCaolán McNamara
Change-Id: I8b2c558c733af3d7662f668af47e962e252ee339 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132311 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-30WASM fix native EH build since Emscripten 3.1.6Jan-Marek Glogowski
Building LO with WASM native EH and Emscripten 3.1.6+, the link fails with a missing "emscripten_longjmp" symbol. Actually the old build was simply wrong, because the emscripten_longjmp function is just used for the Emscripten SjLj and not the native WASM SjLj implementation. Linking just worked, because the used libcompiler_rt-wasm-sjlj-mt.a lib was incorrectly providing that symbol, which 3.1.6 removed. But since running the NEH build still fails early in the same way then before in FF nightly 100 and Chrome (= failure in the LO job scheduler calling Task::UpdateMinPeriod for the "desktop::Desktop m_firstRunTimer" timer, resulting in a WASM VM "RuntimeError: indirect call signature mismatch"), there is still no way to know, if nothing else it missing. The Emscripten / JS EH build still works without any code changes. And it's not the first call on a job object that fails... And unfortunatly, because Qt itself also uses libpng, it also uses SjLj for error handling, like LO in the image import, so the Qt build must also be patched to build with "-s SUPPORT_LONGJMP=wasm". Simply enough to do (see README.wasm.md). LO's configure now detects that symbol and will bail out on incompatible Qt and LO build setup. See https://github.com/emscripten-core/emscripten/issues/16572 Change-Id: I3a1877f3aeb77873906176b9d3cd1ea92973f1f6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132139 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-03-30ofz#46165 ubsan Divide-by-zeroCaolán McNamara
Change-Id: I5c56eae4456a03550770035610745de3be074679 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132299 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-25forcepoint#88 temp std::string assigned to std::string_viewCaolán McNamara
Change-Id: I128a60b68a3af988e3a4bdb06994f43d9b18d67e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132102 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-25forcepoint#87 Assertion 'mp_char <= mp_end' failedCaolán McNamara
Change-Id: I434928cb2425a2e8eb9440dff67f52cda241b2d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132097 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-24forcepoint#83 forcepoint#84 update to upstream fixCaolán McNamara
Change-Id: I5add09b4379a1f86a720af75b758389424f4f50b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132055 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-24forcepoint#84 Invalid read of size 1Caolán McNamara
Change-Id: I1d0d74940cfa78a3c88cee737c9535acf03e0f19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131991 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-23forcepoint#83 Invalid read of size 1Caolán McNamara
Change-Id: I1576dfd8c9731d943107764aeb66bb1c2294ad5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131983 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-19reduce down to the part and config we are using and move to toolsCaolán McNamara
Change-Id: Ifaddc59c3c7834808d368c138a5ec7c0b80db14c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131850 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-17external: update pdfium to 4933Miklos Vajna
Stop tracking build_config.h in our repo, it can be now part of the release tarball. It was a mistake in the past to think that this is generated code, it's just external code. Change-Id: Ife2fed362e28c53859399244e2f1247efb1efe86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131695 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2022-03-09ofz#45373 and ofz#45362 fix ubsan issuesCaolán McNamara
replace the home grown 16.16 fixed math with an alternative Change-Id: If6fa4205aed62ff15157a8ab4dbf9b7c96e30216 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131236 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-07ofz: Use-of-uninitialized valueCaolán McNamara
Change-Id: I67063e20f5fc3c3418ee3db5c7a1f3e4a4a7121c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131100 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-03-04external/python3: Avoid "ThreadSanitizer: destroy of a locked mutex"Stephan Bergmann
..when building ExternalProject_python3 with Clang -fsanitize=thread, > WARNING: ThreadSanitizer: destroy of a locked mutex (pid=973799) > #0 in AnnotateRWLockDestroy at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/tsan/rtl/tsan_interface_ann.cpp:184:3 (workdir/UnpackedTarball/python3/python +0x498460) > #1 in recreate_gil at workdir/UnpackedTarball/python3/Python/ceval_gil.h:138:5 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xe84aa9) > #2 in _PyEval_ReInitThreads at workdir/UnpackedTarball/python3/Python/ceval.c:350:5 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xe847c7) > #3 in PyOS_AfterFork_Child at workdir/UnpackedTarball/python3/./Modules/posixmodule.c:469:5 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x1163dbd) > #4 in os_fork_impl at workdir/UnpackedTarball/python3/./Modules/posixmodule.c:6253:9 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x11adcad) > #5 in os_fork at workdir/UnpackedTarball/python3/./Modules/clinic/posixmodule.c.h:2750:12 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x117b481) > #6 in cfunction_vectorcall_NOARGS at workdir/UnpackedTarball/python3/Objects/methodobject.c:463:24 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x9db7e1) > #7 in _PyObject_Vectorcall at workdir/UnpackedTarball/python3/./Include/cpython/abstract.h:127:11 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xf0225e) > #8 in call_function at workdir/UnpackedTarball/python3/Python/ceval.c:4963:13 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xef3f4a) > #9 in _PyEval_EvalFrameDefault at workdir/UnpackedTarball/python3/Python/ceval.c:3469:23 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0xedc5d8) [...] > #143 in pymain_run_python at workdir/UnpackedTarball/python3/Modules/main.c:610:21 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x1149f6c) > #144 in Py_RunMain at workdir/UnpackedTarball/python3/Modules/main.c:689:5 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x11495e9) > #145 in pymain_main at workdir/UnpackedTarball/python3/Modules/main.c:719:12 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x114a299) > #146 in Py_BytesMain at workdir/UnpackedTarball/python3/Modules/main.c:743:12 (workdir/UnpackedTarball/python3/libpython3.8d.so.1.0 +0x114a30d) > #147 in main at workdir/UnpackedTarball/python3/./Programs/python.c:16:12 (workdir/UnpackedTarball/python3/python +0x4d00f8) Assuming that the GIL is always locked before the fork, better tell TSan about a fake RELEASED before telling it about a fake DESTROY, to keep TSan's model consistent. Change-Id: I6c68d7e415aa0ffc3047e5a5c4c4aca6b0cce8cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130985 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-25Drop support for $host_os = 'macos*', in addition to 'darwin*'Stephan Bergmann
...which had originally been added with baab4f890c8ac99d1b8dab5790fbb7ab949100ab "Initial WIP steps for building for macOS on Apple Silicon" for unclear reasons (just stating "use 'darwin' (or 'macos')" in the commit message), and then further improved with 5a0991c9cd60b6ab10fe0665511e7749a0c0ecc2 "mac: allow cross compiling with host/build x86_64-apple-macos". But it turns out that manually specifying --host or --build =...-macos rather than =...-darwin has issues as discussed in the comments at <https://gerrit.libreoffice.org/c/core/+/130353> "icu: override platform flags for MacOS build", and which can hopefully be avoided by not allowing =...-macos in the first place, and rather forcing people to specify =...-darwin. Change-Id: Ib100b7270250083eba4146430e967073a8cbca46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130505 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-25Upgrade external/boost to latest Boost 1.78.0Stephan Bergmann
<https://dev-www.libreoffice.org/src/boost_1_78_0.tar.xz> has been generated (on Fedora 35) with > $ wget https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/boost_1_78_0.tar.bz2 > --2022-02-24 12:05:39-- https://boostorg.jfrog.io/artifactory/main/release/1.78.0/source/boost_1_78_0.tar.bz2 > $ printf '8681f175d4bdb26c52222665793eef08490d7758529330f98d3b29dd0735bccc boost_1_78_0.tar.bz2' | sha256sum -c # cf. <https://www.boost.org/users/history/version_1_78_0.html> > boost_1_78_0.tar.bz2: OK > $ external/boost/repack_tarball.sh boost_1_78_0.tar.bz2 > Unpacking boost_1_78_0.tar.bz2 ... > Removing unnecessary files ... > Creating boost_1_78_0.tar.xz ... > Cleaning up ... > 0df00d3699c2c7c7fd490c5e165a3e72641861ea5d26428de2f008fb9a75659f boost_1_78_0.tar.xz > Done. external/boost/boost_1_60_0.undef.warning.patch was obsoleted by <https://github.com/boostorg/config/commit/9e80993844cb3d69bfdfa10f059706d7f22eb324> "Define __clang_major___WORKAROUND_GUARD" Change-Id: I7e59ef01ace4ff3c28a285e978e63279b119b07d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130514 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-23external/python3: Explicitly check that all extension modules got builtStephan Bergmann
...to avoid issues like we now experienced on Jenkins box tb76, where e.g. <https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/108402/> failed with just an unhelpful > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/external/python3/ExternalPackage_python3.mk:46: *** file /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/workdir/UnpackedTarball/python3/LO_lib/_elementtree.cpython-3.8d.so does not exist in the tarball. Stop. > make[1]: *** Waiting for unfinished jobs.... > Makefile:299: recipe for target 'build' failed > make: *** [build] Error 2 after ExternalProject_python3 had been built successfully, outputting just > [build PRJ] python3 even though its workdir/UnpackedTarball/python3/build.log states > *** WARNING: renaming "_elementtree" since importing it failed: pyexpat version is incompatible and > Following modules built successfully but were removed because they could not be imported: > _elementtree (but which got hidden by gbuild) Change-Id: I28904ef41cb823e308bb8e15cbe969872702cb55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130355 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-22add system-dragonboxRene Engelhard
Missed in 9eb9083ff2fdaeb96399a0830a4394de4e29ef64 Change-Id: I1d001b39f55c8504a76bfbdadd1423b414adc9c5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130209 Tested-by: René Engelhard <rene@debian.org> Reviewed-by: René Engelhard <rene@debian.org>
2022-02-21external/skia: Missing include (for std::max)Stephan Bergmann
Change-Id: If15570311857b3d5c7a44777f20df446a0d91ab6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130245 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-20WASM fix orcus native exception handling (NEH)Jan-Marek Glogowski
While this fixes the build with --enable-wasm-exceptions, the resulting binary generates an "indirect call signature mismatch", which doesn't happen with the non-NEH build. The Chrome DWARF backtrace points to CallbackTaskScheduling(). Further debugging reveals, it's actually the UpdateMinPeriod call for the "desktop::Desktop m_firstRunTimer" Timer. Disturbingly the debug dynamic_cast<Timer> at the start of the job loop fails, and the fallback generic job output is chosen, AKA: info:vcl.schedule: 6516 0x3871618 i: 0 a: 1 p: 1 \ desktop::Desktop m_firstRunTimer m_firstRunTimer is a Timer member in the Desktop class, so this looks like some memory corruption or toolchain problem. The size difference is more then 10% and it's supposed to be faster too. FWIW the optimized link time is still high and needs 32GB+ memory compared to the 13GB non-optimized memory usage. Change-Id: I06d37ecece09000fd3b72a73e7bf40f0b0f61457 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130216 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-02-18boost: use utf-8 encoding for unknown locales.Michael Meeks
More exotic locales like es-419 cannot be parsed by boost, so we fall-back to the default encoding. This avoids an exception: invalid_charset_error of the form: "Invalid or unsupported charset:us-ascii or UTF-8" for this case. Change-Id: I6796dd893ec774b221956ea9febbcc19495d47b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130102 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2022-02-17Use Dragonbox to implement doubleTo*String*Mike Kaganski
This header-only library is accurate in decimal representation of doubles; provides API that allows to create custom representation - so it's possible to use custom decimal separators and grouping. This allows to unify all corner cases: integers, numbers close to DBL_MAX, up-rounding to the next decade. Note that Dragonbox creates the shortest decimal representation of the number, that is unambiguously convertible back to the same number; thus it may hide trailing digits that are unneeded for such conversion. The functional changes are minimal, and beneficial: 1. Rounding numbers close to DBL_MAX now takes into account the bEraseTrailingDecZeros argument, as it should, allowing to have "1.8E+308" for rounding DBL_MAX to 2 decimals without trailing zeroes, instead of previous "1.80E+308". 2. Incorrect rounding is fixed in some cases, e.g. 9.9999999999999929 rounded to 10 previously using rtl_math_DecimalPlaces_Max. 3. Representing the number in the shortest way may change display of some printed numbers. E.g., 5th greatest double is represented as "1.797693134862315E+308" instead of a bit longer, but giving the same double on roundtrip, "1.7976931348623149E+308". This would generally look better for some numbers similar to the famous 0.1, where users would likely expect more "round" representation where it's unambiguous (but we still truncate to 15 significant decimals anyway - so there's no point in pretending to provide exact digits for actual binary representation). These are reflected in the unit tests affected by the change. Change-Id: I05e20274a30eec499593ee3e9ec070e1269232a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129948 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2022-02-17libxslt: upgrade to release 1.1.35Michael Stahl
Fixes CVE-2021-30560 Change-Id: I334662ddc40955780321133be9aee23858e04dc1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130065 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-02-16Remove apparently obsolete external/boost/boost-android-unified.patch.1Stephan Bergmann
The two checks for __clang_major__ == 5 etc. had been added with 23a8d5ffbbe58761b89f590f0735abccd69a3681 "Upgrade external/boost to Boost 1.69.0" because "with the non-standard Clang 5.0.300080 from NDK r16b, the build now caused failures". But for our current Android build baseline NDK r19c (cf. README.md), > $ android-ndk-r19c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --version > Android (5058415 based on r339409) clang version 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec746213857d083c0e8b0abb568790) (https://android.googlesource.com/toolchain/llvm 7a6618d69e7e8111e1d49dc9e7813767c5ca756a) (based on LLVM 8.0.2svn) [...] has __clang_major__ == 8 by now. Change-Id: I5a5131c14ddf410ed60337992c2d827792c3bbc5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130029 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-10cross-toolset: fix galleries build with webpJan-Marek Glogowski
All the tested cross builds don't build galleries, so the cross-toolset won't contain gengal and no vcl is build. To fix the full static build, add LIBWEBP to the list of PERMITTED_BUILD_TARGETS and use gb_CONFIGURE_PLATFORMS to provide the --host and --build flags. Regression from commit 60eaa424c5e213f31227008e1ed66a646491a360 ("support for the WebP image format (tdf#114532)"). Change-Id: I017c4fc72456859616d535ddfb2d568442ffa446 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129790 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-02-08external/libwebp: Support clang-clStephan Bergmann
...fixing > Makefile.vc(18) : fatal error U1050: Unable to auto-detect toolchain architecture! If cl.exe is in your PATH rerun nmake with ARCH=<arch>. because workdir/UnpackedTarball/libwebp/Makefile.vc naively relies on cl.exe- specific output details in > !IFNDEF ARCH > !IF ! [ $(CC) 2>&1 | grep -q "x86" > NUL ] > ARCH = x86 > !ELSE IF ! [ $(CC) 2>&1 | grep -q "x64" > NUL ] > ARCH = x64 > !ELSE IF ! [ $(CC) 2>&1 | grep -q "ARM" > NUL ] > ARCH = ARM > !ELSE > !ERROR Unable to auto-detect toolchain architecture! \ > If cl.exe is in your PATH rerun nmake with ARCH=<arch>. > !ENDIF > !ENDIF Change-Id: I376295fc75d6ab19773e53dbb607d3b156fbe948 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129655 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-07boost / gettext warning improvement.Michael Meeks
std::runtime_exception of: "Invalid or unsupported charset:UTF-8 or UTF-8" is less useful than it could be when spat out from the boost gettext impl. Survive for the next (and probably more useful) exception. Change-Id: Ibeb60b4a34f09f47051844c3e8048f38618d0e05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129566 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
2022-01-31support for the WebP image format (tdf#114532)Luboš Luňák
This commit implements a WebP reader and writer for both lossless and lossy WebP, export dialog options for selecting lossless/lossy and quality for lossy, and various internal support for the format. Since writing WebP to e.g. ODT documents would make those images unreadable by previous versions with no WebP support, support for that is explicitly disabled in GraphicFilter, to be enabled somewhen later. Change-Id: I9b10f6da6faa78a0bb74415a92e9f163c14685f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128920 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.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>
2022-01-31upgrade to expat 2.4.4Caolán McNamara
Change-Id: Ie141268793dc4332d8c253bec4e986894682c7a6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129179 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
generated by cgit (git 2.34.1) at 2025-01-16 00:25:56 +0000