summaryrefslogtreecommitdiff
path: root/cui
ModeNameSize
-rw-r--r--AllLangResTarget_cui.mk1990logplain
-rw-r--r--Library_cui.mk6129logplain
-rw-r--r--Makefile478logplain
-rw-r--r--Module_cui.mk537logplain
-rw-r--r--README208logplain
-rw-r--r--UIConfig_cui.mk7332logplain
d---------inc / pch30logplain
d---------source233logplain
d---------uiconfig / ui29logplain
d---------util41logplain
generated by cgit (git 2.34.1) at 2025-02-28 15:48:53 +0000
9.0.1/bin/clang: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /home/tdf/lode/opt_private/clang-llvmorg-9.0.1/bin/clang) (because that clang is built against a local GCC and libstdc++, so needs LD_LIBRARY_PATH to be set up properly to find the latter), which caused the gethostbyname check to fail (as seen when looking into that build's workdir/UnpackedTarball/curl/config.log). Change-Id: I3d45018cdfdb22b98c0dec0757e754a172a811de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128850 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-01-22upgrade to curl-7.81.0Caolán McNamara Change-Id: I0a34239bfb16bf19e25bf374c7f36c4cdf1776c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128783 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2021-12-06Better workaround for ASan use-after-poisonStephan Bergmann ...than ae36ee4f3aa544e53e2edad93d6d79160b27bc9d "Work around use-after-poison" for > ==1922539==ERROR: AddressSanitizer: use-after-poison on address > 0x61d00190fab0 at pc 0x00000026aaa9 bp 0x7f422ee84b80 sp > 0x7f422ee84348 WRITE of size 192 at 0x61d00190fab0 thread T44 #0 in > memset at > ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:800:3 > (instdir/program/soffice.bin +0x26aaa8) #1 at <null> > (/lib64/libnsspem.so +0x15f3d) #2 at <null> (/lib64/libnsspem.so > +0x16185) #3 at <null> (/lib64/libnsspem.so +0x8a9b) #4 at <null> > (/lib64/libnsspem.so +0xe13b) #5 in secmod_ModuleInit at > workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11load.c:244:11 > (instdir/program/libnss3.so +0x4ad372) #6 in secmod_LoadPKCS11Module > at workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11load.c:544:10 > (instdir/program/libnss3.so +0x4b1fca) #7 in SECMOD_LoadModule at > workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11pars.c:1946:10 > (instdir/program/libnss3.so +0x50de92) #8 in SECMOD_LoadUserModule > at workdir/UnpackedTarball/nss/nss/lib/pk11wrap/pk11pars.c:2042:28 > (instdir/program/libnss3.so +0x50e9a9) #9 in nss_load_module at > workdir/UnpackedTarball/curl/lib/vtls/nss.c:1310:12 > (instdir/program/libcurl.so.4 +0x4fdd25) #10 in nss_setup_connect at > workdir/UnpackedTarball/curl/lib/vtls/nss.c:1894:12 > (instdir/program/libcurl.so.4 +0x4eeffb) #11 in nss_connect_common > at workdir/UnpackedTarball/curl/lib/vtls/nss.c:2235:14 > (instdir/program/libcurl.so.4 +0x4ee237) #12 in > nss_connect_nonblocking at > workdir/UnpackedTarball/curl/lib/vtls/nss.c:2291:10 > (instdir/program/libcurl.so.4 +0x4ebe4a) #13 in > Curl_ssl_connect_nonblocking at > workdir/UnpackedTarball/curl/lib/vtls/vtls.c:361:12 > (instdir/program/libcurl.so.4 +0x514039) #14 in https_connecting at > workdir/UnpackedTarball/curl/lib/http.c:1591:12 > (instdir/program/libcurl.so.4 +0x2f29ce) #15 in Curl_http_connect at > workdir/UnpackedTarball/curl/lib/http.c:1517:14 > (instdir/program/libcurl.so.4 +0x2f23d5) #16 in protocol_connect at > workdir/UnpackedTarball/curl/lib/multi.c:1696:16 > (instdir/program/libcurl.so.4 +0x3b8620) #17 in multi_runsingle at > workdir/UnpackedTarball/curl/lib/multi.c:1997:16 > (instdir/program/libcurl.so.4 +0x3a2232) #18 in curl_multi_perform > at workdir/UnpackedTarball/curl/lib/multi.c:2568:14 > (instdir/program/libcurl.so.4 +0x39dc5c) #19 in > http_dav_ucp::CurlProcessor::ProcessRequestImpl(http_dav_ucp::CurlSession&, > http_dav_ucp::CurlUri const&, curl_slist*, > com::sun::star::uno::Reference<com::sun::star::io::XOutputStream> > const*, com::sun::star::uno::Sequence<signed char> const*, > std::pair<std::__debug::vector<rtl::OUString, > std::allocator<rtl::OUString> > const&, http_dav_ucp::DAVResource&> > const*, (anonymous namespace)::ResponseHeaders&) at > ucb/source/ucp/webdav-curl/CurlSession.cxx:880:14 > (instdir/program/../program/libucpdav1.so +0x5aad30) 0x61d00190fab0 > is located 48 bytes inside of 2048-byte region > [0x61d00190fa80,0x61d001910280) allocated by thread T44 here: #0 in > malloc at > ~/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:69:3 > (instdir/program/soffice.bin +0x2d3c7e) #1 in PR_Malloc at > workdir/UnpackedTarball/nss/nspr/out/pr/src/malloc/../../../../pr/src/malloc/prmem.c:448:55 > (instdir/program/libnspr4.so +0x123629) #2 in PL_ArenaAllocate at > workdir/UnpackedTarball/nss/nspr/out/lib/ds/../../../lib/ds/plarena.c:134:27 > (instdir/program/libplds4.so +0x9a32) #3 at <null> > (/lib64/libnsspem.so +0x15f77) during UITest_sw_options: That --with-system-nss workaround for <https://ci.libreoffice.org/job/lo_ubsan/> had caused CppunitTest_desktop_lib to start to fail there, presumably "caused by --with-system-nss on the CentOS7 baseline", see the mail thread starting at <https://lists.freedesktop.org/archives/libreoffice/2021-December/088136.html> "Re: [global-libreoffice-ci] UBSAN Linux Build - Build # 2217 - Still Failing!" And while I had initially not been able to reproduce the use-after-poison during UITest_sw_options with my local ASan+UBSan build (on Fedora 35), I now found out that that was just because my machine happened to not have an nsspem library installed in the system (the nss-pem RPM on Fedora). With that system library installed, my local build failed UITest_sw_options in the same way as the Jenkins tinderbox. Which lead me to the idea of avoiding the whole mess by avoiding that CUrl loads the (apparently optional) nsspem library in ASan builds altogether. (Another approach might have been to disable the __asan_poison_memory_region functionality in workdir/UnpackedTarball/nss/nspr/lib/ds/plarena.h, but the chosen approach nicely makes us less dependent on accidental differences in build-time execution environments, at least for ASan builds.) Change-Id: I8fd2ff255771622f26ad666ca78a6d9ded0af2d7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2021-11-17support ccache for MSVC tooLuboš Luňák There's no official MSVC support in ccache yet, but there are patches in progress of getting upstreamed. So right now it's necessary to get a patched ccache. Ccache cannot work with -Zi option, since sharing debuginfo in a .PDB cannot be cached. Added --enable-z7-symbols that gets enabled by default if ccache is detected. It works even with PCHs enabled, and externals seem to work too. I get almost 100% hit rate on a rebuild, although such a rebuild is slower than on Linux. Change-Id: I1d230ee1fccc441b9d9bec794cc2e1ec13161999 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125179 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2021-11-01curl: build with zlib on WNTMichael Stahl Change-Id: I53eb6ed41fb8a17a79f72807df15822e9c1c6e88 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124290 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> 2021-11-01curl: patch invalid format string in debug logMichael Stahl This causes: soffice.bin: sendf.c:243: Curl_infof: Assertion `!strchr(fmt, '\n')' failed. Change-Id: I5a78b2225f6769cc49025e1e73ce72cd3d6bec16 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122963 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> 2021-07-22curl: upgrade to release 7.78.0Michael Stahl * Fixes CVE-2020-8284 CVE-2021-22924 * Also fixes these which don't look relevant to LO: CVE-2020-8231 CVE-2020-8285 CVE-2020-8286 CVE-2021-22876 CVE-2021-22890 CVE-2021-22897 CVE-2021-22898 CVE-2021-22901 CVE-2021-22922 CVE-2021-22923 CVE-2021-22925 CVE-2021-22926 * disable some new protocols and dependencies * remove curl-ios.patch.1 as the code no longer exists upstream Change-Id: I12d5f87f4d503a5f9859226a05cfe2a07e46d993 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119313 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> 2020-09-23tdf#128136: Build curl, nss, and xmlsec for iOS, tooTor Lillqvist We must link nss statically, including the three dylibs that normally are loaded at run-time, because including bare dylibs in an iOS appp on the App Store is not OK. See https://developer.apple.com/forums/thread/125796 . For linking the softokn3 library statically, NSS already had code, behind NSS_STATIC_SOFTOKEN ifdefs. Introduce two more macros: NSS_STATIC_FREEBL for the freebl library and NSS_STATIC_PKCS11 for the nssckbi library. Turn off parallelism for the sub-make building nss. There seems to be race conditions or something when running simultaneous instances of the nsinstall.py script or the nsinstall program in nss (used when building nss for the build platform). When cross-compiling from macOS, use python3 to run the nsinstall.py script, as it is Python 3. Change-Id: Idd427b5ebf21f802b3feb0d5a3d259317ba8fc67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103106 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103218 Tested-by: Jenkins 2020-07-05Use up-to-date config.{guess,sub} for external/curl, tooTor Lillqvist Change-Id: I65741410e9ba14326a6ad7a676d1dfb10006e34f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97988 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>