summaryrefslogtreecommitdiff
path: root/external
AgeCommit message (Collapse)Author
2021-03-12enable libpng hardware optimizations (such as SSE)Luboš Luňák
The implementation is rather poor, but it's still something. Change-Id: Id0a967d55d079327ae41d5dd3446a492fd247cfe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112361 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-03Remove workaround now its fixed in AFL++ and oss-fuzz updatedStephan Bergmann
remove workaround for problem fixed by: https://github.com/AFLplusplus/AFLplusplus/commit/333509bb0a56be9bd2e236f0e2f37d4af2dd7d59> +# "better unicode support" for now: oss-fuzz updated: https://github.com/google/oss-fuzz/pull/5273 Change-Id: Id3f1790ef452ed7732032801fc4ec028e57443eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111806 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-03-03update Skia to chrome/m90Luboš Luňák
Including chrome/m89, which wasn't included before because of tdf#140023. Change-Id: I64f1de8e10eab2d92a9383ce8104be5afca40101 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111792 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-03-02Build libvisio with user CXXFLAGSVincent LE GARREC
Related with commit 8ae9d4727d8010a8f5d51f76ff0ebc5f88f0709f Change-Id: Ic38585f5f5ea5a633a67026d2640e0c43ea43f2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111503 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2021-02-24ofz#30767 Build-FailureCaolán McNamara
similar to commit 63a9b50a7a062069af3e3bcf05657164179baa83 afl++ build crashes for some obscure reason. Tweaking the code like so gets it to squeak by and continue the build. Change-Id: I8cf477320eab19913c1bb65d9ccb779d9c37c8aa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111491 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-24Build internal icu with user CFLAGSVincent LE GARREC
I have a Gentoo (Linux) with libxml2 built with icu support. Under Gentoo, icu is built with U_DISABLE_RENAMING=1. Building LibreOffice with internal icu uses system libxml2. So both builds need CFLAGS="U_DISABLE_RENAMING=1" to avoid naming conflicts. Change-Id: I565c4ac079aee5e48a1e43f21d0a697e3498f925 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111276 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Michael Stahl <michael.stahl@allotropia.de>
2021-02-19tdf#140332: Can't use System V semaphores in a sandboxed macOS processTor Lillqvist
See https://developer.apple.com/library/archive/documentation/Security/Conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html , "Note: System V semaphores are not supported in sandboxed apps". So use POSIX semaphores instead. Change-Id: I37c910cf13b868ab15fe31f90e42d24a9a24eeb1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111239 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-02-15tdf#140234: Fix xmlsec on Windows 7Aron Budea
Apply 21bbcb04b62352331a15a0b8463ebb27a9b858bc from upstream locally. Change-Id: Icb1ca245ebb6453040fbce6da54d13086970b0e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110846 Tested-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-08Revert "update Skia to chrome/m89" (tdf#140023)Luboš Luňák
That update started using SkSamplingOptions to specify image scaling quality. Some places using SkImage::makeShader() should use the quality instead of default SkSamplingOptions ctor, but even with that fix the test document still uses the default nearest quality. Since chrome/m90 will introduce further changes related to this, I'll just revert to m88 and revisit this with m90. This reverts commit 2cf9b8e265e9694803f55e30f2f392abfa512a5a. Change-Id: Iea0e57b7e7b804675d393e4088532a6f617bfd43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110541 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-02-03postgresql: try to cargo-cult MSBuild argumentsMichael Stahl
Extremely unclear to me whether these are useful or necessary, but the other MSBuild ones have them. Change-Id: Iacdd1a1e326bd9ae7c918f5b143495f613ff41d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110385 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-02-03don't build third_party/bigint for pdfiumRene Engelhard
since it's apparently not needed. builds fine even after removing it Change-Id: I5626c8f9920c3e33d91afd51610b815ffae4ed86 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110131 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-02-01tdf#136368 bump to libnumbertext 1.0.7László Németh
– New language modules: Irish, Luganda, Maltese and Marathi – tdf#136368 fix Old Hungarian transliteration – Fixes in Finnish, Thai and Ukrainian language modules. See https://github.com/Numbertext/libnumbertext/releases/tag/1.0.7 and https://github.com/Numbertext/libnumbertext/blob/1.0.7/ChangeLog Change-Id: If98c6098e5d66a4fee8c316e10c8c8a69202e10f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110235 Tested-by: Jenkins Reviewed-by: László Németh <nemeth@numbertext.org>
2021-02-01Drop FAR/NEAR from 16-bit WinAPI timesMike Kaganski
Change-Id: Idf71c662138c281333a83cc76a9d75cbf086f362 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110236 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-28mac: allow cross compiling with host/build x86_64-apple-macosChristian Lohmaier
apple silicon supports to cross compile without special build-tools/full cross-compiling setup, so just always pass the build/host for firebird. firebird and nss don't recognize the -macos specifier, so substitute it by -darwin to make those happy… Change-Id: I953317fc87da2a20dc91acd88c8528796c3b2a69 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110093 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-28nss: makefile bitrot: no need for android spcial case anymoreChristian Lohmaier
check for AARCH64 is done for all OS now, so get rid of the superfluous statement. The all-OS line was initially ARM64 for apple silicon, then AARCH64 was added in addtion since that is what ~all other tools use as label - and finally use withing LO was also unified to use AARCH64 and ARM64 was removed… Change-Id: Ief7e5d8bd399c839ff2910fa91ca5bbbff4bcf31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110080 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-27A patch chunk should have an equal number of context lines before and afterTor Lillqvist
Some versions of the patch program are picky about that. Change-Id: I0006ecefcf4afe10971c5f3571c3d32d97598696 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109998 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-01-24upload libodfgen 0.1.8David Tardon
Change-Id: Ibc59469b74d54a2b307ea708ea5c4a752532f0b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109840 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2021-01-22Fix use of -fvisibility=hidden with Clang in external/libcdr, external/libqxpStephan Bergmann
At least on macOS x86-64 you get a warning > [build LNK] Library/libwpftdrawlo.dylib > ld: warning: direct access in function 'std::__1::__shared_ptr_pointer<librevenge::RVNGInputStream*, std::__1::shared_ptr<librevenge::RVNGInputStream>::__shared_ptr_default_delete<librevenge::RVNGInputStream, librevenge::RVNGInputStream>, std::__1::allocator<librevenge::RVNGInputStream> >::__get_deleter(std::type_info const&) const' from file 'workdir/UnpackedTarball/libzmf/src/lib/.libs/libzmf-0.0.a(ZMFDocument.o)' to global weak symbol 'typeinfo for std::__1::shared_ptr<librevenge::RVNGInputStream>::__shared_ptr_default_delete<librevenge::RVNGInputStream, librevenge::RVNGInputStream>' from file 'workdir/UnpackedTarball/libcdr/src/lib/.libs/libcdr-0.1.a(CDRDocument.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. The reason is that libzmf uses -fvisibility=hidden and generates > $ nm -m workdir/UnpackedTarball/libzmf/src/lib/.libs/libzmf-0.0.a | grep __ZTINSt3__110shared_ptrIN10librevenge15RVNGInputStreamEE27__shared_ptr_default_deleteIS2_S2_EE > 0000000000006dd8 (__DATA,__const) weak private external __ZTINSt3__110shared_ptrIN10librevenge15RVNGInputStreamEE27__shared_ptr_default_deleteIS2_S2_EE while libcdr erroneously does not use -fvisibility=hidden and generates > $ nm -m workdir/UnpackedTarball/libcdr/src/lib/.libs/libcdr-0.1.a | grep __ZTINSt3__110shared_ptrIN10librevenge15RVNGInputStreamEE27__shared_ptr_default_deleteIS2_S2_EE > 00000000000072b8 (__DATA,__const) weak external __ZTINSt3__110shared_ptrIN10librevenge15RVNGInputStreamEE27__shared_ptr_default_deleteIS2_S2_EE The reason for that error is as follows: workdir/UnpackedTarball/libcdr/configure.ac uses, among other things, the result of AX_GCC_FUNC_ATTRIBUTE([visibility]) when deciding whether to use -fvisibility=hidden. And the old ("serial 5") workdir/UnpackedTarball/libcdr/m4/ax_gcc_func_attribute.m4 decides "no" if its test compilation generates any warning output. But Clang on macOS generates > conftest.cpp:34:56: warning: target does not support 'protected' visibility; using 'default' [-Wunsupported-visibility] > int foo_pro( void ) __attribute__((visibility("protected"))); > ^ and lots of > conftest.cpp:2:9: warning: macro is not used [-Wunused-macros] > #define PACKAGE_NAME "libcdr" > ^ (because of -Wunused-macros set for Clang in solenv/gbuild/platform/com_GCC_defs.mk). Same issue with external/libqxp, which would cause > [LNK] Library/libwpftdrawlo.dylib > ld: warning: direct access in function 'std::__1::__shared_ptr_pointer<librevenge::RVNGInputStream*, std::__1::shared_ptr<librevenge::RVNGInputStream>::__shared_ptr_default_delete<librevenge::RVNGInputStream, librevenge::RVNGInputStream>, std::__1::allocator<librevenge::RVNGInputStream> >::__get_deleter(std::type_info const&) const' from file 'workdir/UnpackedTarball/libcdr/src/lib/.libs/libcdr-0.1.a(CDRDocument.o)' to global weak symbol 'typeinfo for std::__1::shared_ptr<librevenge::RVNGInputStream>::__shared_ptr_default_delete<librevenge::RVNGInputStream, librevenge::RVNGInputStream>' from file 'workdir/UnpackedTarball/libqxp/src/lib/.libs/libqxp-0.0.a(QXPMacFileParser.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. <http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=commitdiff; h=df0894ad1a8195df67a52108b931e07d708cec9a> "ax_gcc_func_attribute: Revise the detection of unknown attributes", even though it was apparently meant to fix something different, nicely fixes this Clang issue, making AX_GCC_FUNC_ATTRIBUTE correctly detect support for visibility now. When building with Clang on Linux, there is no -Wunsupported-visibility about __attribute__((visibility("protected"))), but all the -Wunused-macros are present as well, which caused all the AX_GCC_FUNC_ATTRIBUTE checks to be mis- detected as "no" there, too. There are more uses of AX_GCC_FUNC_ATTRIBUTE in workdir/UnpackedTarball/libcdr/configure.ac and workdir/UnpackedTarball/libqxp/configure.ac, and there are many more workdir/UnpackedTarball/*/m4/ax_gcc_func_attribute.m4 in other external projects, all of which may cause similar AX_GCC_FUNC_ATTRIBUTE mis-detections. However, they do not cause any noticeable traces like the "direct access" ld warning here, so I left those alone for now. (Ultimately, all the upstream external projects should probably deploy the latest version of ax_gcc_func_attribute.m4 from <http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain; f=m4/ax_gcc_func_attribute.m4>.) Change-Id: Ia0560cace770ec7da9ee390566a01a5c592f9209 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109774 Tested-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-20update Skia to chrome/m89Luboš Luňák
Change-Id: I82517728139a4b270d98e2694f2a21b248c80d4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109568 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-01-20postgresql: upgrade to release 13.1Michael Stahl
Fixes CVE-2020-25694, plus a bunch more CVE that don't look relevant. * --with-krb5 no longer exists, neither does --disable-shared * remove internal-zlib.patch.1: zlib is only used by pg_* tools / contrib/pgcrypto * remove postgresql-libs-leak.patch: some relic from pre-gbuild times, not clear what the point is for static libs * remove postgresql-9.2.1-libreoffice.patch: another dmake .mk file relic, and the win32 nmake build system was removed * add postgres-msvc-build.patch.1 to fix Cygwin perl and openssl * on WNT, libpq.dll is now built, no longer static lib Change-Id: Ic0232a28801b2f604d9f4e33d5621ae3362defaa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109640 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-01-19nss: fix parallel build race in nsinstall.pyMichael Stahl
File "/home/tdf/lode/jenkins/workspace/android_aarch64/external/nss/nsinstall.py", line 112, in nsinstall os.makedirs(args[0]) File "/opt/rh/rh-python38/root/usr/lib64/python3.8/os.py", line 223, in makedirs mkdir(name, mode) FileExistsError: [Errno 17] File exists: '../../../../dist/public/dbm' ../../../coreconf/rules.mk:119: recipe for target '../../../../dist/public/dbm/d' failed Change-Id: I4273e6d3d5fa520353fff8738823ef281fe237ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109619 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-01-18mac: don't put script files into Contents/MacOS or framework-bin directoryChristian Lohmaier
Signing them as executable code would require external attributes, and those in turn break packaging into hfs+ dmg when building on apfs with Big Sur. It is not a new thing - the old Code Signing in Depth technote https://developer.apple.com/library/archive/technotes/tn2206/_index.html already reads: "Store Python, Perl, shell, and other script files and other non-Mach-O executables in your app's Contents/Resources directory. While it's possible to sign such executables and store them in Contents/MacOS, this is not recommended. […] Put another way, a properly-signed app that has all of its files in the correct places will not contain any signatures stored as extended attributes." The patch does exactly that for LO and the shipped python framework and adds symlinks for the moved files. Same applies for the Language pack applescript and the tarball - those are also moved into Contents/Resources Change-Id: Iab21e77b73f941248ca89c6e80703fdf67a1057c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109537 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-01-14external/boost: Silence Boost bind deprecation warningStephan Bergmann
> In file included from desktop/source/lib/lokinteractionhandler.cxx:22: > In file included from external/boost/include/boost/property_tree/json_parser.hpp:30: > In file included from workdir/UnpackedTarball/boost/boost/property_tree/json_parser.hpp:16: > In file included from workdir/UnpackedTarball/boost/boost/property_tree/json_parser/detail/read.hpp:13: > In file included from workdir/UnpackedTarball/boost/boost/property_tree/json_parser/detail/parser.hpp:7: > In file included from external/boost/include/boost/bind.hpp:30: > workdir/UnpackedTarball/boost/boost/bind.hpp:36:1: warning: The practice of declaring the Bind placeholders (_1, _2, ...) in the global namespace is deprecated. Please use <boost/bind/bind.hpp> + using namespace boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior. [-W#pragma-messages] > BOOST_PRAGMA_MESSAGE( > ^ etc. from within boost/property_tree/json_parser.hpp wherever that is included, since e0f1b5bd94550835c639efda4e4c9a801c78dbe9 "Upgrade external/boost to latest Boost 1.75.0". Change-Id: I2c780966e4774a8d58d1cbdf21f77d685da00689 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109229 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-13external: update pdfium to 4380Miklos Vajna
Allows dropping 5 upstreamed patches. Change-Id: I5f77502c5a2d11288b060956e69fd7767f52ab97 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109195 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2021-01-11Fix -Werror,-Wundef in Skia (at least for Raspberry pi 4)Julien Nabet
Detected on Raspberry pi 4, for example: In file included from /home/pi/lo/libreoffice/vcl/skia/SkiaHelper.cxx:34: In file included from /home/pi/lo/libreoffice/vcl/inc/skia/utils.hxx:28: In file included from /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkRegion.h:11: In file included from /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkRect.h:11: In file included from /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkPoint.h:11: In file included from /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkMath.h:11: /home/pi/lo/libreoffice/workdir/UnpackedTarball/skia/include/core/SkTypes.h:371:5: error: 'SK_CPU_SSE_LEVEL' is not defined, evaluates to 0 [-Werror,-Wundef] if SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE1 ^ ... but there are others, see: http://document-foundation-mail-archive.969070.n3.nabble.com/Building-LO-on-Raspberry-pi-4b-error-unknown-attribute-externally-visible-on-jni-part-tt4293505.html Since it may happen on some other envs and it can't be bad to explicitely initialize this preproc var, it seems relevant to use this patch unconditionally. Change-Id: Icc5794fcd3139cbdbd8d57a6938d31aee51a3e2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109047 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-01-07faster debug dumping for SkiaLuboš Luňák
Write out the png images as quickly as possible, with still at least minimal compression. Without compression the debug images are way too big, but otherwise it's preferred that this is fast (especially when possibly dumping thousands of images). Skia's PNG code ignores the quality and hardcodes the libpng defaults, so patch Skia to explicitly handle the quality we want. It'd be also possible to use SkPngEncoder directly, but SkImage makes it non-trivial to get at the pixel data if it's on the GPU, and the internal getROPixels() invoked by encodeToData() also caches the content, so be lazy and patch Skia. Change-Id: I09cc61115246de4fc9d076953eb7fec8140c32cb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108668 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-01-07Add missing include for std::for_eachMike Kaganski
It is reported now by Windows build after e0f1b5bd94550835c639efda4e4c9a801c78dbe9 "Upgrade external/boost to latest Boost 1.75.0". Change-Id: Ia69c74cd72c7e8ce56c56ffbfb1c1e467ce2bdc6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108932 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-01-07poppler: upgrade to release 21.01.0Michael Stahl
Fixes CVE-2020-27778 and changelogs mention lots of fuzzing fixes. Change-Id: Ib07bdee726905e74afc13a01bbbd53f218121744 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108912 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-01-07external/libebook: Missing include (for std::min)Stephan Bergmann
...as reported now by various Windows builders after e0f1b5bd94550835c639efda4e4c9a801c78dbe9 "Upgrade external/boost to latest Boost 1.75.0" Change-Id: Ib1f4ea2ca05003b24347c7233bd06cef7d4c955f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108920 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-06Upgrade external/boost to latest Boost 1.75.0Stephan Bergmann
* <https://dev-www.libreoffice.org/src/boost_1_75_0.tar.xz> has been generated (on Fedora 33) with > $ wget https://dl.bintray.com/boostorg/release/1.75.0/source/boost_1_75_0.tar.bz2 > $ printf '953db31e016db7bb207f11432bef7df100516eeb746843fa0486a222e3fd49cb boost_1_75_0.tar.bz2' | sha256sum -c # cf. <https://www.boost.org/users/history/version_1_75_0.html> > boost_1_75_0.tar.bz2: OK > $ external/boost/repack_tarball.sh boost_1_75_0.tar.bz2 > Unpacking boost_1_75_0.tar.bz2 ... > Removing unnecessary files ... > Creating boost_1_75_0.tar.xz ... > Cleaning up ... > cc378a036a1cfd3af289f3da24deeb8dba7a729f61ab104c7b018a622e22d21b boost_1_75_0.tar.xz > Done. * external/boost/StaticLibrary_boost_date_time.mk: Even though date_generators.cpp and greg_weekday.cpp are still present, their function definitions are now covered by inline function definitions in include files, > workdir/UnpackedTarball/boost/libs/date_time/src/gregorian/greg_weekday.cpp:23:17: error: redefinition of 'as_short_string' > greg_weekday::as_short_string() const > ^ > workdir/UnpackedTarball/boost/boost/date_time/gregorian/greg_weekday.hpp:52:17: note: previous definition is here > const char* as_short_string() const > ^ etc. and > workdir/UnpackedTarball/boost/libs/date_time/src/gregorian/date_generators.cpp:23:36: error: redefinition of 'nth_as_str' > BOOST_DATE_TIME_DECL const char* nth_as_str(int ele) > ^ > workdir/UnpackedTarball/boost/boost/date_time/date_generators.hpp:157:22: note: previous definition is here > inline const char* nth_as_str(int ele) > ^ * external/boost/StaticLibrary_boost_filesystem.mk now lacked various symbols, as seen when linking external/liborcus' orcus-parser library: > "boost::filesystem::emit_error(int, boost::system::error_code*, char const*)", referenced from: [...] > "boost::filesystem::emit_error(int, boost::filesystem::path const&, boost::system::error_code*, char const*)", referenced from: [...] > "boost::filesystem::emit_error(int, boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code*, char const*)", referenced from: [...] > "boost::filesystem::filesystem_error::filesystem_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, boost::filesystem::path const&, boost::system::error_code)", referenced from: [...] > "boost::filesystem::filesystem_error::filesystem_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, boost::filesystem::path const&, boost::filesystem::path const&, boost::system::error_code)", referenced from: [...] > "boost::filesystem::filesystem_error::~filesystem_error()", referenced from: [...] > "boost::filesystem::detail::dir_itr_close(void*&, void*&)", referenced from: [...] > "boost::filesystem::detail::directory_iterator_construct(boost::filesystem::directory_iterator&, boost::filesystem::path const&, unsigned int, boost::system::error_code*)", referenced from: [...] > "boost::filesystem::detail::directory_iterator_increment(boost::filesystem::directory_iterator&, boost::system::error_code*)", referenced from: [...] > "typeinfo for boost::filesystem::filesystem_error", referenced from: [...] * No longer sure why external/boost/gcc9.patch.0 from e7b8728f5c0292a6c6a18e76220b1769ecf25aa3 "external/boost: silence -Werror=deprecated-copy (GCC trunk towards GCC 9)" was necessary at all, in addition to that commit's > #pragma GCC diagnostic ignored "-Wdeprecated-copy" changes, but at least a build with recent GCC 11 trunk appears to work fine now without it. (And the patch would no longer have applied as-is.) * The dropped patches in external/boost/c++20-allocator.patch.0 and external/boost/clang-cl.patch.0 would no longer have applied as-is, but also appear not to be needed any more. * external/boost/include/boost/property_tree/ptree_fwd.hpp became necessary to silence > In file included from workdir/UnpackedTarball/boost/boost/property_tree/ptree_fwd.hpp:16, > from libreofficekit/qa/gtktiledviewer/gtv-helpers.hxx:21, > from libreofficekit/qa/gtktiledviewer/gtv-application-window.cxx:19: > workdir/UnpackedTarball/boost/boost/throw_exception.hpp: In instantiation of ‘boost::wrapexcept<E>::wrapexcept(const E&, const boost::source_location&) [with E = boost::property_tree::ptree_bad_data]’: > workdir/UnpackedTarball/boost/boost/throw_exception.hpp:171:11: required from ‘void boost::throw_exception(const E&, const boost::source_location&) [with E = boost::property_tree::ptree_bad_data]’ > workdir/UnpackedTarball/boost/boost/property_tree/detail/ptree_implementation.hpp:826:13: required from ‘void boost::property_tree::basic_ptree<Key, Data, KeyCompare>::put_value(const Type&, Translator) [with Type = char [8]; Translator = boost::property_tree::stream_translator<char, std::char_traits<char>, std::allocator<char>, char [8]>; Key = std::__cxx11::basic_string<char>; Data = std::__cxx11::basic_string<char>; KeyCompare = std::less<std::__cxx11::basic_string<char> >]’ > workdir/UnpackedTarball/boost/boost/property_tree/detail/ptree_implementation.hpp:845:34: required from ‘boost::property_tree::basic_ptree<K, D, C>& boost::property_tree::basic_ptree<Key, Data, KeyCompare>::put(const path_type&, const Type&, Translator) [with Type = char [8]; Translator = boost::property_tree::stream_translator<char, std::char_traits<char>, std::allocator<char>, char [8]>; Key = std::__cxx11::basic_string<char>; Data = std::__cxx11::basic_string<char>; KeyCompare = std::less<std::__cxx11::basic_string<char> >; boost::property_tree::basic_ptree<Key, Data, KeyCompare>::path_type = boost::property_tree::string_path<std::__cxx11::basic_string<char>, boost::property_tree::id_translator<std::__cxx11::basic_string<char> > >]’ > workdir/UnpackedTarball/boost/boost/property_tree/detail/ptree_implementation.hpp:859:19: required from ‘boost::property_tree::basic_ptree<K, D, C>& boost::property_tree::basic_ptree<Key, Data, KeyCompare>::put(const path_type&, const Type&) [with Type = char [8]; Key = std::__cxx11::basic_string<char>; Data = std::__cxx11::basic_string<char>; KeyCompare = std::less<std::__cxx11::basic_string<char> >; boost::property_tree::basic_ptree<Key, Data, KeyCompare>::path_type = boost::property_tree::string_path<std::__cxx11::basic_string<char>, boost::property_tree::id_translator<std::__cxx11::basic_string<char> > >]’ > libreofficekit/qa/gtktiledviewer/gtv-application-window.cxx:300:103: required from here > workdir/UnpackedTarball/boost/boost/throw_exception.hpp:134:82: error: implicitly-declared ‘boost::property_tree::ptree_bad_data::ptree_bad_data(const boost::property_tree::ptree_bad_data&)’ is deprecated [-Werror=deprecated-copy-dtor] > 134 | explicit wrapexcept( E const & e, boost::source_location const & loc ): E( e ) > | ^ > In file included from workdir/UnpackedTarball/boost/boost/property_tree/exceptions.hpp:84, > from workdir/UnpackedTarball/boost/boost/property_tree/string_path.hpp:16, > from workdir/UnpackedTarball/boost/boost/property_tree/ptree.hpp:16, > from external/boost/include/boost/property_tree/ptree.hpp:30, > from workdir/UnpackedTarball/boost/boost/property_tree/json_parser.hpp:14, > from external/boost/include/boost/property_tree/json_parser.hpp:30, > from libreofficekit/qa/gtktiledviewer/gtv-application-window.cxx:26: > workdir/UnpackedTarball/boost/boost/property_tree/detail/exception_implementation.hpp:51:12: note: because ‘boost::property_tree::ptree_bad_data’ has user-provided ‘virtual boost::property_tree::ptree_bad_data::~ptree_bad_data()’ > 51 | inline ptree_bad_data::~ptree_bad_data() throw() > | ^~~~~~~~~~~~~~ etc. Change-Id: I36fcd04ca6f109910761a5802535a18cfb17ddd9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108878 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-06openssl: upgrade to release 1.1.1iMichael Stahl
Fixes CVE-2020-1971 * openssl-macos-arm64.patch.1: remove, was fixed upstream Change-Id: I405270228682025bf26240e3ea923bfd234068f5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108804 Tested-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-01-06external/boost: Backport a Boost 1.72.0 fixStephan Bergmann
...for issues with MSVC 2019 16.8.3 --with-latest-c++ in external/libwpd: > [build CXX] workdir/UnpackedTarball/libwpd/src/lib/libwpd_internal.cpp > C:\lo\core\workdir\UnpackedTarball\boost\boost/proto/generate.hpp(239): error C2039: 'value': is not a member of 'boost::proto' > C:\lo\core\workdir\UnpackedTarball\boost\boost/proto/generate.hpp(32): note: see declaration of 'boost::proto' > C:\lo\core\workdir\UnpackedTarball\boost\boost/proto/generate.hpp(239): note: This diagnostic occurred in the compiler generated function 'Extends<boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<MemberClass::* >,boost::proto::argsns_::term<MemberClass::* >::arity>> boost::proto::pod_generator<Extends>::operator ()(const boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal,boost::proto::argsns_::term<MemberClass::* >,boost::proto::argsns_::term<MemberClass::* >::arity> &) const' > C:\lo\core\workdir\UnpackedTarball\boost\boost/proto/generate.hpp(252): note: see reference to class template instantiation 'boost::proto::pod_generator<Extends>' being compiled [...] Change-Id: Iae62b41e09b89bd387efab2744d47d938a868d17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108839 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-06external/clucene: Fix MSVC /Zc:strictStringsStephan Bergmann
...which is apparently enabled at least in MSVC 2019 16.8.3 when building with --with-latest-c++ (i.e., /std:c++latest): > C:/lo/core/workdir/UnpackedTarball/clucene/src/contribs-lib/CLucene/analysis/PorterStemmer.cpp(124): error C2664: 'bool lucene::analysis::PorterStemmer::ends(TCHAR *)': cannot convert argument 1 from 'const wchar_t [5]' to 'TCHAR *' > C:/lo/core/workdir/UnpackedTarball/clucene/src/contribs-lib/CLucene/analysis/PorterStemmer.cpp(124): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) > C:/lo/core/workdir/UnpackedTarball/clucene/src/contribs-lib/CLucene/analysis/PorterStemmer.cpp(97): note: see declaration of 'lucene::analysis::PorterStemmer::ends' etc. (and which is not silenced by gb_Library_set_warnings_disabled in external/clucene/Library_clucene.mk, unlike the corresponding Clang/GCC -Wwrite-strings) Change-Id: Id3c8eefa4658bf942de6c8ae9b219212eba79995 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108840 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-01-03Fix nss build on Raspberry pi4Julien Nabet
In file included from gcm-arm32-neon.c:16: /usr/lib/llvm-11/lib/clang/11.0.0/include/arm_neon.h:32:2: error: "NEON support not enabled" error "NEON support not enabled" ^ gcm-arm32-neon.c:21:5: warning: implicit declaration of function 'vst1_u8' is invalid in C99 [-Wimplicit-function-declaration] vst1_u8(outbuf, vrev64_u8(vcreate_u8(ghash->x_high))); ^ gcm-arm32-neon.c:21:21: warning: implicit declaration of function 'vrev64_u8' is invalid in C99 [-Wimplicit-function-declaration] vst1_u8(outbuf, vrev64_u8(vcreate_u8(ghash->x_high))); ^ gcm-arm32-neon.c:21:31: warning: implicit declaration of function 'vcreate_u8' is invalid in C99 [-Wimplicit-function-declaration] vst1_u8(outbuf, vrev64_u8(vcreate_u8(ghash->x_high))); ^ gcm-arm32-neon.c:27:15: error: unknown type name 'uint8x16_t'; did you mean 'uint16_t'? static inline uint8x16_t ^~~~~~~~~~ uint16_t /usr/include/arm-linux-gnueabihf/bits/stdint-uintn.h:25:20: note: 'uint16_t' declared here typedef __uint16_t uint16_t; ^ gcm-arm32-neon.c:28:13: error: unknown type name 'uint8x8_t'; did you mean 'uint8_t'? clmul(const uint8x8_t a, const uint8x8_t b) ^~~~~~~~~ uint8_t etc. Change-Id: I1e241cea5becb159f8b0f898270dc88f93f68670 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108634 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-02Fix build error in Python3 for Raspberry pi4bJulien Nabet
/home/pi/lo/libreoffice/external/python3/ExternalPackage_python3.mk:48: *** file /home/pi/lo/libreoffice/workdir/UnpackedTarball/python3/LO_lib/_sysconfigdata__linux_armv7l-unknown-linux-gnueabihf.py does not exist in the tarball. Arrêt. Change-Id: If348c9f55883c1afcc37ff38e84361786bef1845 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108595 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-01Removed executable bits from patch fileAndrea Gelmini
Change-Id: I6cbfbfe32fb1d70cd8f73add0c2f6a63117e7f4f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108560 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-01-01Use Unicode paths on Windows in libnumbertextMike Kaganski
Change-Id: I02790afc314c8633a24dbf23001f3d5cffe169b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108478 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-12-29external/firebird: Fix MSVC /Zc:strictStringsStephan Bergmann
> C:/lo/core/workdir/UnpackedTarball/firebird/src/auth/trusted/AuthSspi.cpp(112): error C2664: 'SECURITY_STATUS (SEC_CHAR *,SEC_CHAR *,unsigned long,void *,void *,SEC_GET_KEY_FN,void *,PCredHandle,PTimeStamp)': cannot convert argument 2 from 'const char [5]' to 'SEC_CHAR *' > C:/lo/core/workdir/UnpackedTarball/firebird/src/auth/trusted/AuthSspi.cpp(112): note: Conversion from string literal loses const qualifier (see /Zc:strictStrings) Not sure why this only started to hit my build now. Change-Id: Idea0a8a2abaafe17183323a31f29173bd71fbeec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108451 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-29external/cairo: Fix mask usage in image-compositorStephan Bergmann
Change-Id: Id3d8e4715e295290e07146ef06898b313ead57a5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108449 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-22pdfium: replace 3 patches with backportsMiklos Vajna
So that vcl/ already uses the upstreamed API and the patches can be just dropped on the next pdfium upgrade. Change-Id: I58f6a4cca37677788d9a2e4e31c2e89d074ad5ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108140 Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Tested-by: Jenkins
2020-12-21ios,nss: use AARCH64 consistentlyMichael Stahl
Presumably missing from 1cee06c080bceab86ac894f8ae86d4d296b050aa Change-Id: I0f658bb36179b741f6f47264ee1400633db69d6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108064 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-17pdfium: backport GetTrailerEnds whitespace fixMiklos Vajna
Fixes the problem that sometimes a valid sig is detected as a partial one. Change-Id: I68107569bf8c331170902b1918a70ea4b9b659a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107856 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-12-14onedrive integration: updating metadata needs to be http PATCHChristian Lohmaier
avoids general i/o error message when adding newly created documents via the "Save remote" menu option. support for PATCH was added with 9cfcf83f53e0ae897b30705f790c6ebe0b86932e but only applied in onedrive-document.cxx OneDriveDocument::setContentStream which has it's own update of properties instead of reusing the method from onedrive-object.cxx Change-Id: I50f8801ac3186953f60198f877cedf3729307b89
2020-12-14tdf#115643 make onedrive work again by switching to graph APIChristian Lohmaier
the live SDK method had been deprecated quite a while ago and has been turned off a while back. Notes: While you can access and save existing files using the remote files dialog, creating new files or using "save as" requires using the LibreOffice open/save dialogs. Authentication is clunky: username and password you're asked when creating a new connection is not used at all for connecting, so only fill out a username to label your onedrive entry. Actual authentication is done in browser - copy'n'paste the URL from the dialog into the browser, login and approve access for LibreOffice (approving access only necessary once), then you get redirected to localhost, ignore that there is nothing to display. The important part is the code from the URL-bar. Copy and paste that into the LibreOffice dialog and LO can request an authentication token for API access. Testing this feature requires compiling with corresponding api-keys specified in configure/having an app registered with microsoft. Change-Id: I2db11ac09f9fdc354a10d6c749b2bec84b5d34a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107646 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-12-09better name for a helper Skia functionLuboš Luňák
What it really does is converting RGBA to R, so name it after what it does. That the result happens to be kind-of-grey of the RGBA is just a result of VCL providing the data that way. Change-Id: Ic017e34d91879679e0a7dad4d6ab35650fc3a89b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107408 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-12-07external/firebird: clang-cl needs -march=x86-64-v2 nowStephan Bergmann
...to avoid > C:/lo/core/workdir/UnpackedTarball/firebird/src/common/CRC32C.cpp(41,10): error: always_inline function '_mm_crc32_u8' requires target feature 'sse4.2', but would be inlined into function 'CRC32C' that is compiled without support for 'sse4.2' > return _mm_crc32_u8(hash_value, *value); > ^ etc. With <https://github.com/FirebirdSQL/firebird/commit/ 52d9a05a0f3d811a9de7f15956ee9286d5711648> "Backport from master", that code appeared on the B3_0_Release branch only after R3_0_1, so was not present in our Firebird-3.0.0.32483-0.tar.bz2 before 86744f03992213af162df6954313c9f9e44e3a0a "firebird: update to 3.0.7". This is apparently about the SSE4.2 CRC32 instruction. Not sure how this works in the MSVC build, whether it implicitly generates code targeting SSE4.2 (<https://docs.microsoft.com/en-us/cpp/build/reference/arch-x64?view=msvc-160> "/arch (x64)" does not mention any switch to explicitly enable it), or whether its _mm_crc32_u* intrinsics would be smart enough to generate code that also works when SSE4.2 is not available at runtime. Change-Id: I893733eb079e6c0eb8b685a55ce09e1fdcd2eda2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107334 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-07More NSS fixes for macOS on arm64Tor Lillqvist
I think the attempt to set CPU_ARCH in external/nss/ExternalProject_nss.mk does not actually work. And anyway, it should be arm64 for macOS on arm64, not aarch64. Now NSS configury correctly finds the APIs present in the system when building for macOS on arm64. Previously, it attempted to compile the test snippets for PowerPC... which caused for instance dladdr() not to be found, which caused the softokn3 loading to fail. (It's somewhat surprising that the NSS configury still has "support" for MacOS on PowerPC... Do people really build latest and greatest NSS on such machines? Or is it just a leftover and the NSS people never, ever, remove anything?) Change-Id: I0dc35df0460db7997efcfdf92594fd8ae352aa49 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107316 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-03external/firebird: extern/cloop: Missing dependency of $(BIN_DIR)/cloop...Stephan Bergmann
...on $(BIN_DIR) Change-Id: I649f2eaafb0e7160f7092a652c38193975fb5982 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107163 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-03Drop Python modules we don't want on macOS, too, like on other platformsTor Lillqvist
On macOS, for various reasons, we use a different approach than on other platforms to construct the bundled Python. Instead of explicitly listing what to include (out of what Python contains and builds) (in ExternalPackage_python3.mk), after Python is built, we remove stuff we don't want (in ExternalProject_python3.mk) and then include everything left in the LibreOfficePython.framework (in GeneratedPackage_python3.mk). This fixes a problem in App Store review: For some reason the review said that the setcchar() function from the ncurses library, used by Python's curses module, is non-public. No idea why the (automated) review picked on that function. As far as I see from the ncurses header in the SDK, that function is no less public than the other ncurses functions that the Python module uses. But oh well, we don't actually ship the curses module anyway on other platforms, so just drop it on macOS, too. And while at it, drop the other unwanted ones, too. And any binary shared libraries for them. Change-Id: Idecaf10a6fb1c59e8711095927f5699b8d2ec98e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107055 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107141 Tested-by: Tor Lillqvist <tml@collabora.com>
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>
generated by cgit (git 2.34.1) at 2025-02-08 06:39:58 +0000