summaryrefslogtreecommitdiff
path: root/external/gpgmepp
AgeCommit message (Collapse)Author
2024-07-25fix pid_t type mismatch on win64 between libassuan and gpgmeppChristian Lohmaier
typedef long long pid_t in case of #ifdef _WIN64 is the only change, the rest of the change to the patch is just rediffing Change-Id: Iaad34bf42ad06fc6a636b773535f199a19c863e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171023 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-07-25libassuan: upgrade to 3.0.1Christian Lohmaier
Downloaded from https://gnupg.org/ftp/gcrypt/libassuan/libassuan-3.0.1.tar.bz2 Change-Id: Ie56dd4d88998c6b2a825a502aa34bae3436d2b25 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/169198 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2024-05-06makefile simplification: replace $(call gb_UnpackedTarball_get_dir,foo)Christian Lohmaier
…by a simple/static $(gb_UnpackedTarball_workdir)/foo see also 0c4c84a14b01c71c76a9c45a7f26aec4d64f3e4f Change-Id: I8e6aa55c85534c4446556548910c950ddbe7c6fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167163 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2024-04-26run autoconf/autoreconf via wsl in wsl-as-helper caseChristian Lohmaier
Change-Id: I9bcdfe352fd378e1bf09e15b8d8f7dcea82c0b5e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166341 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-03-22Clean up path in diff header linePatrick Luby
Change-Id: I181c8c0f41bd4367c622352797f4c493e16c02c7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165165 Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-03-21tdf#152524 fix crash by skipping second fork()Patrick Luby
Instead of calling a second fork() in the child process, replace execv() with posix_spawn(). posix_spawn() does not call any atfork handlers so the atfork handler that crashes will be skipped. Change-Id: Iffb70fe4f51b6b324f13e4ac24b740da0a25da99 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165103 Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-02-27GPGME: upgrade to release 1.23.2Taichi Haradaguchi
Change-Id: I56c419fbbe615ef57b7d8117ccdc32f0daddf95f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163840 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-23Revert "tdf#152524 use dispatch_async() instead of dispatch_sync()"Patrick Luby
This reverts commit b0656e6ca668a0719fbcb71b6d46c68093dda470. Reason for revert: This patch has not made any positive difference for tdf#152524. Change-Id: I5ea0f80263188049f06623ac930b4dc7856dc53e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163758 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-02-08tdf#152524 use dispatch_async() instead of dispatch_sync()Patrick Luby
Commit 839cf255e2670fdf8e974af38432aacf63be4e90 used dispatch_sync() but, unfortunately, libdispatch will not create a new thread for the queue. dispatch_async_and_wait() also doesn't necessary run the queue in a separate thread so use dispatch_async() and block and wait for the libdispatch task to complete. Change-Id: I8babad30caa8a188483ddf4f62bae35f5b888dc8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163122 Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com> Tested-by: Jenkins Reviewed-by: Patrick Luby <guibomacdev@gmail.com>
2024-02-07tdf#152524 fork() and exec() in a separate libdispatch queuePatrick Luby
This is another attempt to stop the crashing in libdispatch by running fork() and exec() within a libdispatch task that will run in a sequential queue in a non-main thread. Change-Id: I3249510c14cc32f7f769b59289fe8380dd22ab68 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163036 Tested-by: Jenkins Tested-by: Caolán McNamara <caolan.mcnamara@collabora.com> Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-07-15Related tdf#155125: add MacPorts to GPG's fallback search on macOSPatrick Luby
Change-Id: I52a5031b531dc542b2eea72191a1c240f78820bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154474 Tested-by: Jenkins Reviewed-by: Patrick Luby <plubius@neooffice.org>
2023-06-27Fix gpgme build on WindowsMike Kaganski
Commit 97c67afac1ec9351d0a64011a7ddfb7dfa876484 (Update gpgme to 1.20.0, 2023-06-23) defined ssize_t in external/gpgmepp/w32-build-fixes.patch.1. It was done to address the use of ssize_t in src/debug.h, appeared in https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=patch;h=7d1159c1e99bb1bae0ab698c85105dcdcb95b7ea This led to build errors like C:\cygwin\home\tdf\lode\jenkins\workspace\lo_tb_master_win64_dbg\workdir\UnpackedTarball\gpgmepp\src\debug.h(26): error C2371: 'ssize_t': redefinition; different basic types C:\cygwin\home\tdf\lode\jenkins\workspace\lo_tb_master_win64_dbg\workdir\UnpackedTarball\libassuan\src\assuan.h(47): note: see declaration of 'ssize_t' To fix it locally, just revert the problematic patch, until fixed upstream. Change-Id: Ib89496cc08b0ce6d24d5c9e9c7e615c6909d071b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153671 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-06-26Update gpgme to 1.20.0Taichi Haradaguchi
* remove external/gpgmepp/0001-cpp-Fix-building-with-C-11.patch.1 and external/gpgmepp/gcc9.patch that were applied upstream. * remove unneccesary external/gpgmepp/macos-include.patch. * remove a bit of external/gpgmepp/w32-build-fixes.patch.1 that was applied upstream. Change-Id: I9982a3a47e62a5e06e3c04ddc3ee3f247eefa8ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153544 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2022-12-15gpgme: upgrade to release 1.18.0Taichi Haradaguchi
Remove gpgme.git-4b64774b6d13ffa4f59dddf947a97d61bcfa2f2e.patch.1 as it has applied in 1.18.0. * 0001-cpp-Fix-building-with-C-11.patch.1: fixed error "no matching function for call to object of type "(lambda at importresult.cpp:154:71)"". * w32-include.patch: add missing #include <string> (for std::string). * macos-include.patch: add missing #include <algorithm> (for std::any_of). Change-Id: I45f2ef415d80e6ee848699803e971f154812c9c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143039 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-09-17external/gpgmepp: Fix various -Wincompatible-function-pointer-typesStephan Bergmann
...after Clang 16 trunk <https://github.com/llvm/llvm-project/commit/af01f717c48f0fd2481600ed6c00441763365b62> "Default implicit function pointer conversions diagnostic to be an error". The changes in workdir/UnpackedTarball/gpgmepp/src/assuan-support.c are due to the difference between ssize_t as used by > ssize_t (*read) (assuan_context_t ctx, assuan_fd_t fd, void *buffer, > size_t size); > ssize_t (*write) (assuan_context_t ctx, assuan_fd_t fd, > const void *buffer, size_t size); in workdir/UnpackedTarball/libassuan/src/assuan.h and gpgme_ssize_t as defined by > #ifdef _WIN64 > # include <stdint.h> > typedef int64_t gpgme_off_t; > typedef int64_t gpgme_ssize_t; > #else /* _WIN32 */ > typedef long gpgme_off_t; > typedef long gpgme_ssize_t; > #endif /* _WIN32 */ in workdir/UnpackedTarball/gpgmepp/src/gpgme.h: > assuan-support.c(353,5): error: incompatible function pointer types initializing 'ssize_t (*)(assuan_context_t, assuan_fd_t, void *, size_t)' (aka 'long (*)(struct assuan_context_s *, void *, void *, unsigned long long)') with an expression of type 'gpgme_ssize_t (assuan_context_t, assuan_fd_t, void *, size_t)' (aka 'long long (struct assuan_context_s *, void *, void *, unsigned long long)') [-Wincompatible-function-pointer-types] > my_read, > ^~~~~~~ > assuan-support.c(354,5): error: incompatible function pointer types initializing 'ssize_t (*)(assuan_context_t, assuan_fd_t, const void *, size_t)' (aka 'long (*)(struct assuan_context_s *, void *, const void *, unsigned long long)') with an expression of type 'gpgme_ssize_t (assuan_context_t, assuan_fd_t, const void *, size_t)' (aka 'long long (struct assuan_context_s *, void *, const void *, unsigned long long)') [-Wincompatible-function-pointer-types] > my_write, > ^~~~~~~~ Change-Id: I71f34da1a14421335a9416dd500a91d94de2f48a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140097 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-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>
2022-01-05Update gpgme to 1.16.0Thorsten Behrens
* remove GPGME_CAN_EXPORT_MINIMAL_KEY, upstream now has support for key export flags in c++ wrapper (gpgmepp >= 1.14) * therefore, external/gpgmepp/add-minimal-keyexport.patch now fully obsolete, tweaked xmlsecurity code to use upstream function * bits of external/gpgmepp/find-libgpg-error-libassuan.patch are upstream now (configure and makefile pieces, though we keep configure.ac changes for the while - to not pick up system versions too easily) * external/gpgmepp/gpgme.git-fe2892618c20cd40c342cce26ffb6ac4644fd3c3.patch.1 was from upstream anyway, removed Change-Id: I991c20c0eeff0f9135e97c991afcb905be55a959 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127665 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-11-04Consolidate -D_GLIBCXX_DEBUG for --enable-dbgutil builds against libstdc++Stephan Bergmann
(this was meant as a prerequisite for enabling its -D_LIBCPP_DEBUG=1 counterpart when building against libc++ on macOS, but which got stalled for now after running into the issue described at <https://lists.llvm.org/pipermail/libcxx-dev/2021-October/001222.html> "[libcxx-dev] Building a program with -D_LIBCPP_DEBUG=1 against a libc++ that is not itself built with that define") Change-Id: If466dce595a9311b2afbae41d5ddcaecc6f3c57b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124678 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-11Fix gpgmepp build with glibcMike Kaganski
posix-io.c: In function '_gpgme_io_spawn': posix-io.c:492:23: error: void value not ignored as it ought to be 492 | while ((i = closefrom (fd)) && errno == EINTR) | ^ make[1]: *** [Makefile:964: posix-io.lo] Error 1 Change-Id: I0e7abc33200ca7436c72e925447e681fd241c6a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123259 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
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-12-03pass verbose down to gpgme buildNoel Grandin
Change-Id: Ia388bc2167925a29c1984920b6913f41611c3073 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107142 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-11-10external/gpgmepp: Adapt to _AC_UNDECLARED_WARNING in autoconf 2.70betaStephan Bergmann
see the linked <https://lists.gnu.org/archive/html/autoconf/2020-11/msg00004.html> "Fallout from _AC_UNDECLARED_WARNING in autoconf 2.70beta" for details Change-Id: I02c0f41d8f9e2ec7f833423a55ccbfff19e5ceb8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105555 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-11WIN cross: fix gpg-related library buildsJan-Marek Glogowski
Cross compiling these libraries requires to supply the cross- compiler via the CC_FOR_BUILD environment variable. Since we have to use the gcc-wrappers, we now need two different invocations with different inclues and libraries, but just have fixed environment variables. Also, the CC_FOR_BUILD clashes with LO's own variant, but that is easy to fix. So this change includes: - gcc-wrappers: new option --wrapper-env-prefix to add a prefix to the environment variable names - gcc-wrappers: new option --wrapper-print-cmdline to dump the real command called, when a verbose build is executed - gcc-wrappers: default to exe, if the output has no extension - unify build flags for gpg related libraries Change-Id: I4e6a6ba3c6e09237c8ffefa40ce61131290a3852 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102482 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-08-05gpgpmepp: fix creative abuse of gbuildMichael Stahl
The problem was that (cd sw && make CppunitTest_sw_ooxmlexport4) fails with an error that the gpgmepp package doesn't exist, but only on WNT. Nonobviously, this is due to the override of the rule for the gpgmepp package in ExternalPackage_gpgmepp.mk, which copies the same file that the package already depends on for no obvious reason. Furthermore, RepositoryExternal.mk uses gb_Helper_register_executables_for_install with gpgme-w32spawn, when it should just register the package instead, because that is not a gbuild Executable. Change-Id: I8cb8b7a68c9681844a39de1390aa736a1ec53449 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100159 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-08-04external/gpgmepp: Avoid overloaded utf8_to_wchar in C codeStephan Bergmann
> w32-util.c(176,1): error: conflicting types for 'utf8_to_wchar' > utf8_to_wchar (const char *string) > ^ > workdir/UnpackedTarball/libgpg-error/src\gpg-error.h(1109,10): note: previous declaration is here > wchar_t *utf8_to_wchar (const char *string, size_t length, size_t *retlen); > ^ with clang-cl on Windows, while in a case like this where there is only one definition, the mismatching declaration merely gets warned about by MSVC with "warning C4029: declared formal parameter list different from definition". (And on non-Windows that w32-util.c apparently doesn't get compiled at all.) Change-Id: I76cfc3ec086325c527c04dbe0e8341cb9b775c50 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100091 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-20external/gpgmepp: Deprecated std::shared_pointer::unique has been removed...Stephan Bergmann
...from C++20, and is no longer provided at least by VS 2019 16.6.4 when using --with-latest-c++ Change-Id: I1812b4c314febe134a299e42362ca50b495f08d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99081 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-06-20gpg4libre: fix build for Linux x86Thorsten Behrens
- as lang/cpp/test/* failed to add LIBASSUAN_LIBS - x86_64 apparently passing due to suitable system lib Change-Id: I8ed3715d656fcec1345731865b0185601cf4dce3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96762 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-06-15tdf#133987: initialize dbg_help to avoid dereferencing stack garbageMike Kaganski
Change-Id: Iee9263db201a544d5fe7e0952b48648ea7a16036 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96323 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-06-15gpg4libre: fix build for CentOS baselineThorsten Behrens
- tests don't work against old baseline libassuan, lets disable also for Linux - remove no-longer-existing --disable-glibtest option Change-Id: Iee4d72944d23e63fa8e75f7391effb9fbcbe4845 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96305 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2020-06-13gpg4libre: update gpgme, libassuan and libgpg-errorThorsten Behrens
seen upstream & removed here: - external/gpgmepp/add-gpgme_set_global_flag-wrapper.patch - external/gpgmepp/version.patch - external/libgpg-error/clang-cl.patch - external/libgpg-error/libgpg-error_gawk5.patch Change-Id: Iea2b681fa839ae55cb954c2ad3edf4291b149dbe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/61322 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
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>
2019-09-03Silence -fsanitize=object-size in --enable-optimized buildsStephan Bergmann
<http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#available-checks> (as of recent LLVM trunk towards LLVM 10) states: "-fsanitize=object-size: An attempt to potentially use bytes which the optimizer can determine are not part of the object being accessed. This will also detect some types of undefined behavior that may not directly access memory, but are provably incorrect given the size of the objects involved, such as invalid downcasts and calling methods on invalid pointers. These checks are made in terms of __builtin_object_size, and consequently may be able to detect more problems at higher optimization levels." A `make check screenshot` with --enabled-optimized runs into two such issues that were not diagnosed with --disable-optimized, in both cases because a struct with an "idiomatic trailing dynamic array member" (statically declared to be an array of size 1) is allocated without any space for that array member, as the dynamic array size is 0 in the specific case: * For > [CUT] sc_ucalc > cppu/source/uno/copy.hxx:46:19: runtime error: member access within address 0x6020001aaa70 with insufficient space for an object of type 'uno_Sequence' (aka '_sal_Sequence') > 0x6020001aaa70: note: pointer points here > 2b 00 80 6a be be be be be be be be 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > ^ > #0 in cppu::allocSeq(int, int) at cppu/source/uno/copy.hxx:46:19 (instdir/program/libuno_cppu.so.3 +0x41f03f) > #1 in uno_type_sequence_reference2One at cppu/source/uno/sequence.cxx:813:20 (instdir/program/libuno_cppu.so.3 +0x41f03f) [...] the call to pNew = allocSeq( 0, 0 ); in uno_type_sequence_reference2One is inlined, so sal_uInt32 nSize = calcSeqMemSize( nElementSize, nElements ); in allocSeq is known to be too small. * For > testSignatureLineODF::TestBody finished in: 2044ms > engine-gpg.c:302:6: runtime error: member access within address 0x604001f24f10 with insufficient space for an object of type 'struct arg_and_data_s' > 0x604001f24f10: note: pointer points here > 6e 01 00 26 be be be be be be be be be be be be be be be be be be be be be be be be be be be be > ^ > #0 in add_data at workdir/UnpackedTarball/gpgmepp/src/engine-gpg.c:302:6 (instdir/program/libgpgme.so.11 +0x120c2b) [...] > make[1]: *** [solenv/gbuild/CppunitTest.mk:114: workdir/CppunitTest/xmlsecurity_signing.test] Error 1 the a = malloc (sizeof *a - 1); is apparently detected to be too small only with optimization enabled. In both cases, the solution is to operate on the too-small dynamically allocated object via a reinterpret_cast'ed pointer to some newly introduced "struct prefix" type. Change-Id: Ie814db1d00a439bb9189474b91d729e538e81984 Reviewed-on: https://gerrit.libreoffice.org/78548 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-28Record patch as upstreamedMike Kaganski
Change-Id: Ia84db6c3d8051b872a838b530a8c44ce4a4b2821 Reviewed-on: https://gerrit.libreoffice.org/78198 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-05-24disable warnings in external libsLuboš Luňák
As in, really disable, so that they do not even show. This moreover avoids tons of D9025 warnings from MSVC about overriding -W4 with -w. Change-Id: Ia2e72fd72d883d91bdd89e467ee42f259e2ae033 Reviewed-on: https://gerrit.libreoffice.org/72899 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-05-05Fix remaining uses of gb_SYMBOLStephan Bergmann
...after eeeec33ada5923f1f534334b22c15d6e2c6f1d35 "merge --enable-selective-debuginfo into --enable-symbols" had removed it Change-Id: I83aed6e21c4b983d8645707daa65bd85ec16ff6b Reviewed-on: https://gerrit.libreoffice.org/71798 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-04-21Properly initialize gpgme-w32spawn.exe path on WindowsMike Kaganski
On Windows, gpgme expects gpgme-w32spawn.exe to be in the same directory as the current process executable. This assumption might be wrong, e.g., for bundled python, which is in instdir/program/python-core-x.y.z/bin, while gpgme-w32spawn.exe is in instdir/program. In this case, if an operation in a python script requires initializing gpgme, it will be interrupted by a modal warning box telling that gpgme-w32spawn.exe was not found. If we can't find gpgme-w32spawn.exe in the current executable location, then try to find the spawn executable, and inform gpgme about actual location using gpgme_set_global_flag. Change-Id: Ie30a0d4a6666767e8c54f1bdc67b67570d6ea47a Reviewed-on: https://gerrit.libreoffice.org/71014 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2019-01-24Drop unnecessary gb_DEBUG_CFLAGSStephan Bergmann
...which was at maximum set to GCC's -finline-limit=0 -fno-inline (solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug builds "since forever", but that looks very much like cargo cult: -fno-inline "is the default when not optimizing" anyway (<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline (and maybe was present for ancient compilers that only supported -finline-limit but not -fno-inline?). Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874 Reviewed-on: https://gerrit.libreoffice.org/66836 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-23Drop use of obsolete GCC -fno-default-inlineStephan Bergmann
...that is documented as: "Does nothing. Preserved for backward compatibility." ever since <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=160384> from 2010. -fno-default-inline was the only value ever set in gb_DEBUG_CXXFLAGS, so the latter can be removed now. The use of gb_DEBUG_CXXFLAGS had accidentally already been removed from gb_LinkTarget__get_debugcxxflags with e751e24250fda31dde52b3c65ca79f86142dc789 "--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutil", and that leaves gb_LinkTarget__get_debugcflags and gb_LinkTarget__get_debugcxxflags with identical definitions, so replace those two with a single gb_LinkTarget__get_debugflags. Some external modules had used only gb_DEBUG_CXXFLAGS, when this was apparently meant to be used in addition to gb_DEBUG_CFLAGS, so those uses have been changed to gb_DEBUG_CFLAGS now. Change-Id: I84ea0ab1233569b0b02ca057240a71f138352381 Reviewed-on: https://gerrit.libreoffice.org/66808 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-10-21Copy gpgme-w32spawn.exe to workdir/LinkTarget/ExecutableMike Kaganski
... to avoid "GpgME not installed correctly" message boxes during unit tests. See the mail list thread started with https://lists.freedesktop.org/archives/libreoffice/2018-October/081209.html Change-Id: Ie57e6b5a7281d8f20ba97912f3413eafaac9cfd4 Reviewed-on: https://gerrit.libreoffice.org/61903 Tested-by: Jenkins Tested-by: Jan-Marek Glogowski <glogow@fbihome.de> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-10-05Record external/gpgmepp/version.patch as sent upstreamStephan Bergmann
Change-Id: Ibc0dc42f3df8c5a4acc1ccece5a4ef63bd04fd39 Reviewed-on: https://gerrit.libreoffice.org/61405 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-10-04external/gpgmepp: Clash between VERSION and trunk libc++ <version>Stephan Bergmann
...on macOS with case-insensitive file systems. When compiling e.g. workdir/UnpackedTarball/gpgmepp/lang/cpp/src/parser/exception.cpp, libtool adds -I../../.. (presumably to find files like workdir/UnpackedTarball/gpgmepp/config.h), and including e.g. <string> internally includes <version> now, and workdir/UnpackedTarball/gpgmepp/VERSION happens to win. So just remove VERSION from the sources, which appears to not be needed at least in our build of gpgmepp. (An alternative approach might have been to use -iquote../../.. instead of -I../../.., but that's probably hard to shoehorn into the libtool-generated compiler invocation.) Change-Id: Ib1a30a6b825cab208238d17ff384e7900a27047d Reviewed-on: https://gerrit.libreoffice.org/61359 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-07-26external/gpgmepp: silence -Werror=deprecated-copy (GCC trunk towards GCC 9)Stephan Bergmann
Change-Id: Ib516eb3c9905577f083b99dd972443dcb3e86a42 Reviewed-on: https://gerrit.libreoffice.org/58043 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-06-27Clarify name and location of external/gpgmepp's upstreamStephan Bergmann
Change-Id: I8f91e5d00e716bbd0e6aa25697e0b30908ffb8bb
2018-03-08Fix external/gpgmepp Linux RPATHStephan Bergmann
In other external projects using libtool, we fix that by patching configure, resetting hardcode_libdir_flag_spec[_CXX] at the end of the linux*) case block that sets the Linux-specific value. But here we run autoreconf in ExternalProject_libassuan, so that patch in configure would be overwritten. The relevant code in configure comes from autoconf boilerplate, so we cannot just do the same patch in configure.ac. But we can reset hardcode_libdir_flag_spec sufficiently late in configure.ac so that things still work as intended. Disable tests that would build executabes linking against libgpgme.so, which in turn links against the libassuan and libgpg-error libs, which would no longer be found by the linker because of the dropped -rpath flags. (Alternatives might be to pass in LD_LIBRARY_PATH or to link with --allow-shlib-undefined.) Change-Id: I7e37abf802d213347bd80383b7980d85cf0762d4 Reviewed-on: https://gerrit.libreoffice.org/50960 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-03-08Improve gpgmepp -> libassuan/libgpg-error lib dependenciesStephan Bergmann
...so that other executables than svidl would benefit, too Change-Id: I208ebbc04189c2f25eace19ef0875349cf63d3f0 Reviewed-on: https://gerrit.libreoffice.org/50963 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-02-20gpgmepp,xmlsecurity: fix testODFEncryptedGPG() failure caused...Michael Stahl
...by CppunitTest setting LD_LIBRARY_PATH to include instdir/program. This causes the spawned gpg-agent to load instdir/program/libassuan.so.0 instead of /usr/... and fail with: writev(2, [{iov_base="gpg-agent", iov_len=9}, {iov_base=": ", iov_len=2}, {iov_base="relocation error", iov_len=16}, {iov_base=": ", iov_len=2}, {iov_base="gpg-agent", iov_len=9}, {iov_base=": ", iov_len=2}, {iov_base="symbol assuan_sock_set_system_ho"..., iov_len=118}, {iov_base="", iov_len=0}, {iov_base="", iov_len=0}, {iov_base="\n", iov_len=1}], 10) = 159 The failure happens in the libreoffice-6-0 branch on Fedora 27, whereas the master branch doesn't fail because it has a newer version of libassuan that happens to provide the required symbol. Fix this by applying the patch that was added for ASAN in d15f042abd5a1093984a0c8380837145f38c4efc to clear LD_LIBRARY_PATH always on Linux. Change-Id: I6a5c7fdfdd32234f39a182581b03d79739880c11 Reviewed-on: https://gerrit.libreoffice.org/50056 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2017-12-12Make --disable-runtime-optimizations not fail when LIBO_LD_PATH is unsetStephan Bergmann
...outside of CppunitTest_xmlsecurity_signing Change-Id: I0679fd3437bdddfdb7b40daddc7c107d9d8fcc90
2017-12-12CppunitTest_xmlsecurity_signing failed in sanitizer buildsStephan Bergmann
...because external/gpgmepp spawns /usr/bin/gpgconf (and later on /usr/bin/ggp2, /usr/bin/gpgsm) which all depend on libgpg-error.so.0, so due to CppunitTest's LD_LIBRARY_PATH will pick up instdir/program/libgpg-error.so.0, which fails due to > /usr/bin/gpgconf: symbol lookup error: /data/sbergman/lo-san/core/instdir/program/libgpg-error.so.0: undefined symbol: __asan_option_detect_stack_use_after_return The easiest fix appears to be, when running sanitizers on Linux, to hack gpgmepp's _gpgme_io_spawn to set LD_LIBRARY_PATH back to its original state. (When it was originally unset, it will now be set but null, but that should not make a difference.) This requires EXTRA_ENV_VARS to be set earlier in CppunitTest.mk, so setting LIBO_LD_PATH doesn't use the LD_LIBRARY_PATH value set in gb_CppunitTest_CPPTESTPRECOMMAND. The backtrace of the first, originally failing call to _gpgme_io_spawn during CppunitTest_xmlsecurity_signing: > #0 0x00007fffe1f354dc in _gpgme_io_spawn (path=0x1 <error: Cannot access memory at address 0x1>, argv=0x7ffff2fbd4e0, flags=0, fd_list=0x9, atfork=0x4e, atforkvalue=0x7ffff2fbd4e0, r_pid=0x7ffff2fbd4e0) at posix-io.c:433 > #1 0x00007fffe1f41971 in read_gpgconf_dirs (pgmname=0x6110002f8e00 "/usr/bin/gpgconf", components=0) at dirinfo.c:206 > #2 0x00007fffe1f3fa29 in get_gpgconf_item (what=12) at dirinfo.c:284 > #3 0x00007fffe1f4073e in _gpgme_get_default_gpg_name () at dirinfo.c:370 > #4 0x00007fffe1e87093 in engine_get_file_name (proto=GPGME_PROTOCOL_OpenPGP) at engine.c:79 > #5 0x00007fffe1e84e89 in gpgme_get_engine_info (info=0x7ffff2a06160) at engine.c:230 > #6 0x00007fffe1e845ef in gpgme_engine_check_version (proto=GPGME_PROTOCOL_OpenPGP) at engine.c:144 > #7 0x00007fffe634e7d9 in GpgME::checkEngine(GpgME::Protocol) (proto=GpgME::OpenPGP) at context.cpp:1610 > #8 0x00007fff8df3fd49 in SecurityEnvironmentGpg::SecurityEnvironmentGpg() (this=0x6060005825c0) at xmlsecurity/source/gpg/SecurityEnvironment.cxx:30 > #9 0x00007fff8df5755e in SEInitializerGpg::createSecurityContext(rtl::OUString const&) (this=0x606000582560) at xmlsecurity/source/gpg/SEInitializer.cxx:45 > #10 0x00007fff8df57bb3 in non-virtual thunk to SEInitializerGpg::createSecurityContext(rtl::OUString const&) () at include/rtl/stringutils.hxx:170 > #11 0x00007fffab66de90 in DocumentSignatureManager::init() (this=0x7ffff2fbb020) at xmlsecurity/source/helper/documentsignaturemanager.cxx:78 > #12 0x00007fffab498504 in DocumentDigitalSignatures::ImplVerifySignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&, DocumentSignatureMode) (this=0x6080001aaf20, rxStorage=uno::Reference to (OStorage *) 0x60d0003a4c48, xSignStream=empty uno::Reference, eMode=DocumentSignatureMode::Content) at xmlsecurity/source/component/documentdigitalsignatures.cxx:264 > #13 0x00007fffab497f8b in DocumentDigitalSignatures::verifyDocumentContentSignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&) (this=0x6080001aaf20, rxStorage=uno::Reference to (OStorage *) 0x60d0003a4c48, xSignInStream=empty uno::Reference) at xmlsecurity/source/component/documentdigitalsignatures.cxx:127 > #14 0x00007fffab49c35b in non-virtual thunk to DocumentDigitalSignatures::verifyDocumentContentSignatures(com::sun::star::uno::Reference<com::sun::star::embed::XStorage> const&, com::sun::star::uno::Reference<com::sun::star::io::XInputStream> const&) () at include/cppu/unotype.hxx:136 > #15 0x00007fffafc062a3 in SfxObjectShell::ImplAnalyzeSignature(bool, com::sun::star::uno::Reference<com::sun::star::security::XDocumentDigitalSignatures> const&) (this=0x61100021c7c0, bScriptingContent=false, xSigner=empty uno::Reference) at sfx2/source/doc/objserv.cxx:1293 > #16 0x00007fffafc074b1 in SfxObjectShell::ImplGetSignatureState(bool) (this=0x61100021c7c0, bScriptingContent=false) at sfx2/source/doc/objserv.cxx:1322 > #17 0x00007fffafc0383d in SfxObjectShell::GetDocumentSignatureState() (this=0x61100021c7c0) at sfx2/source/doc/objserv.cxx:1485 > #18 0x00007fffafbb323c in SfxObjectShell::CheckForBrokenDocSignatures_Impl() (this=0x61100021c7c0) at sfx2/source/doc/objmisc.cxx:981 > #19 0x00007fffafbb2da4 in SfxObjectShell::CheckSecurityOnLoading_Impl() (this=0x61100021c7c0) at sfx2/source/doc/objmisc.cxx:931 > #20 0x00007fffafbb95cf in SfxObjectShell::FinishedLoading(SfxLoadedFlags) (this=0x61100021c7c0, nFlags=SfxLoadedFlags::ALL) at sfx2/source/doc/objmisc.cxx:1079 > #21 0x00007fff716a9185 in SwDocShell::LoadingFinished() (this=0x61100021c7c0) at sw/source/uibase/app/docsh.cxx:1153 > #22 0x00007fff71759ada in SwDocShell::Load(SfxMedium&) (this=0x61100021c7c0, rMedium=...) at sw/source/uibase/app/docshini.cxx:581 > #23 0x00007fffafc2bd9a in SfxObjectShell::LoadOwnFormat(SfxMedium&) (this=0x61100021c7c0, rMedium=...) at sfx2/source/doc/objstor.cxx:2971 > #24 0x00007fffafc3128c in SfxObjectShell::DoLoad(SfxMedium*) (this=0x61100021c7c0, pMed=0x60300083dac0) at sfx2/source/doc/objstor.cxx:714 > #25 0x00007fffafdd88d8 in SfxBaseModel::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x6190000fb0b0, seqArguments=uno::Sequence of length 13 = {...}) at sfx2/source/doc/sfxbasemodel.cxx:1788 > #26 0x00007fffb049a98a in (anonymous namespace)::SfxFrameLoader_Impl::load(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&, com::sun::star::uno::Reference<com::sun::star::frame::XFrame> const&) (this=0x6060004aaec0, rArgs=uno::Sequence of length 11 = {...}, _rTargetFrame=uno::Reference to ((anonymous namespace)::Frame *) 0x6160000c63f0) at sfx2/source/view/frmload.cxx:693 > #27 0x00007fff82d6a7ee in framework::LoadEnv::impl_loadContent() (this=0x7ffff2fe3040) at framework/source/loadenv/loadenv.cxx:1105 > #28 0x00007fff82d5aa6b in framework::LoadEnv::startLoading() (this=0x7ffff2fe3040) at framework/source/loadenv/loadenv.cxx:374 > #29 0x00007fff82d56633 in framework::LoadEnv::loadComponentFromURL(com::sun::star::uno::Reference<com::sun::star::frame::XComponentLoader> const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (xLoader=uno::Reference to (framework::Desktop *) 0x6160000153f8, xContext=uno::Reference to (cppu::ComponentContext *) 0x611000002b10, sURL="file:///xmlsecurity/qa/unit/signing/data/goodGPG.odt", sTarget="_default", nFlags=0, lArgs=uno::Sequence of length 2 = {...}) at framework/source/loadenv/loadenv.cxx:160 > #30 0x00007fff82ec93f0 in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x616000015380, sURL="file:///xmlsecurity/qa/unit/signing/data/goodGPG.odt", sTargetFrameName="_default", nSearchFlags=0, lArguments=uno::Sequence of length 2 = {...}) at framework/source/services/desktop.cxx:618 > #31 0x00007fff82ec95eb in non-virtual thunk to framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () at include/rtl/stringutils.hxx:170 > #32 0x00007fffabe3097d in unotest::MacrosTest::loadFromDesktop(rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) (this=0x60c000035e48, rURL="file:///xmlsecurity/qa/unit/signing/data/goodGPG.odt", rDocService="com.sun.star.text.TextDocument", rExtraArgs=empty uno::Sequence) at unotest/source/cpp/macros_test.cxx:50 > #33 0x00007fffb2ba9d2a in SigningTest::createDoc(rtl::OUString const&) (this=0x60c000035e00, rURL="file:///xmlsecurity/qa/unit/signing/data/goodGPG.odt") at xmlsecurity/qa/unit/signing/signing.cxx:204 > #34 0x00007fffb2bd1532 in SigningTest::testODFGoodGPG() (this=0x60c000035e00) at xmlsecurity/qa/unit/signing/signing.cxx:690 > #35 0x00007fffb2c304fd in std::__invoke_impl<void, void (SigningTest::*&)(), SigningTest*&>(std::__invoke_memfun_deref, void (SigningTest::*&)(), SigningTest*&) (__f=@0x6030001f0480: (void (SigningTest::*)(SigningTest * const)) 0x7fffb2bd0d80 <SigningTest::testODFGoodGPG()>, __t=@0x6030001f0490: 0x60c000035e00) at /usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/invoke.h:73 > #36 0x00007fffb2c300e0 in std::__invoke<void (SigningTest::*&)(), SigningTest*&>(void (SigningTest::*&)(), SigningTest*&) (__fn=@0x6030001f0480: (void (SigningTest::*)(SigningTest * const)) 0x7fffb2bd0d80 <SigningTest::testODFGoodGPG()>, __args=@0x6030001f0490: 0x60c000035e00) at /usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/invoke.h:95 > #37 0x00007fffb2c2ff2f in std::_Bind<void (SigningTest::*(SigningTest*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (this=0x6030001f0480, __args=...) at /usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/functional:467 > #38 0x00007fffb2c2fb23 in std::_Bind<void (SigningTest::*(SigningTest*))()>::operator()<, void>() (this=0x6030001f0480) at /usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/functional:549 > #39 0x00007fffb2c2e8d1 in std::_Function_handler<void (), std::_Bind<void (SigningTest::*(SigningTest*))()> >::_M_invoke(std::_Any_data const&) (__functor=...) at /usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/std_function.h:316 > #40 0x00007fffb2c30b1c in std::function<void ()>::operator()() const (this=0x608000083660) at /usr/lib/gcc/x86_64-redhat-linux/7/../../../../include/c++/7/bits/std_function.h:706 > #41 0x00007fffb2c2db41 in CppUnit::TestCaller<SigningTest>::runTest() (this=0x608000083620) at workdir/UnpackedTarball/cppunit/include/cppunit/TestCaller.h:175 > #42 0x00007ffff78fc159 in CppUnit::TestCaseMethodFunctor::operator()() const (this=0x7ffff2e9c0d0) at TestCase.cpp:32 > #43 0x00007fffdc3cc8e3 in (anonymous namespace)::Protector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (this=0x602000019910, functor=...) at test/source/vclbootstrapprotector.cxx:48 > #44 0x00007ffff78ccf96 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const (this=0x6030002189e0) at ProtectorChain.cpp:20 > #45 0x00007fffe8938ab3 in (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (this=0x6020000003f0, functor=...) at unotest/source/cpp/unobootstrapprotector/unobootstrapprotector.cxx:89 > #46 0x00007ffff78ccf96 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const (this=0x603000218a10) at ProtectorChain.cpp:20 > #47 0x00007fffebc1e492 in (anonymous namespace)::Prot::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (this=0x602000000250, functor=..., context=...) at unotest/source/cpp/unoexceptionprotector/unoexceptionprotector.cxx:63 > #48 0x00007ffff78ccf96 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const (this=0x603000218a40) at ProtectorChain.cpp:20 > #49 0x00007ffff7863084 in CppUnit::DefaultProtector::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (this=0x602000000150, functor=..., context=...) at DefaultProtector.cpp:15 > #50 0x00007ffff78ccf96 in CppUnit::ProtectorChain::ProtectFunctor::operator()() const (this=0x603000218a70) at ProtectorChain.cpp:20 > #51 0x00007ffff78c68f5 in CppUnit::ProtectorChain::protect(CppUnit::Functor const&, CppUnit::ProtectorContext const&) (this=0x60b000000510, functor=..., context=...) at ProtectorChain.cpp:86 > #52 0x00007ffff795e259 in CppUnit::TestResult::protect(CppUnit::Functor const&, CppUnit::Test*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (this=0x7ffff2f000a0, functor=..., test=0x608000083620, shortDescription="") at TestResult.cpp:182 > #53 0x00007ffff78fa785 in CppUnit::TestCase::run(CppUnit::TestResult*) (this=0x608000083620, result=0x7ffff2f000a0) at TestCase.cpp:91 > #54 0x00007ffff798c2fe in CppUnit::TestRunner::WrappingSuite::run(CppUnit::TestResult*) (this=0x608000081820, result=0x7ffff2f000a0) at TestRunner.cpp:47 > #55 0x00007ffff795ccdf in CppUnit::TestResult::runTest(CppUnit::Test*) (this=0x7ffff2f000a0, test=0x608000081820) at TestResult.cpp:149 > #56 0x00007ffff798d23f in CppUnit::TestRunner::run(CppUnit::TestResult&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (this=0x7ffff2f4db00, controller=..., testPath="") at TestRunner.cpp:96 > #57 0x000000000052e3a9 in (anonymous namespace)::ProtectedFixtureFunctor::run() const (this=0x7ffff2f00350) at sal/cppunittester/cppunittester.cxx:319 > #58 0x000000000052ae38 in sal_main() () at sal/cppunittester/cppunittester.cxx:469 > #59 0x0000000000529e2c in main(int, char**) (argc=23, argv=0x7fffffff2798) at sal/cppunittester/cppunittester.cxx:376 Change-Id: I386a3b316c78344c2449568894c0f03ba39b1bf0 Reviewed-on: https://gerrit.libreoffice.org/46249 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-02-09 14:18:42 +0000