summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-12-07More NSS fixes for macOS on arm64private/tml/lov-7.0.3.3Tor Lillqvist1-2/+19
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-05Remove remaining bogus use of objc_msgSend()Tor Lillqvist5-28/+7
Follow-up to 5bf61e98b0746a4afeb68a80e54b4eb4bf4ea89f. Should avoid crashes when running as arm64 code on macOS on arm64. Change-Id: Id05d182684df82c8a7bf09f6bb7e8ccb01997b62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107259 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-05Fix crash or hang on macOS on arm64 when opening a file pickerTor Lillqvist2-8/+2
There is no reason to not mention the NSOpenSavePanelDelegate protocol that AquaFilePickerDelegate implements. The way we used objc_msgSend() caused a crash or hang. (I saw both, depending on whether the code was built for debugging or not). For some reason we used to cast it to a function with variadic parameters like: reinterpret_cast<id (*)(id, SEL, ...)>(objc_msgSend)( m_pDialog, @selector(setDelegate:), m_pDelegate); This does not work in arm64 code on macOS. (See https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code?language=objc , the "Don't Redeclare a Function to Have Variable Parameters" section.) We could have replaced the ellipsis with the actual type of the first real parameter in this call, or just "id" would have worked fine. But it is much simpler to just do what we mean directly: [m_pDialog setDelegate:m_pDelegate]; I need to look through the code for other places where we have used objc_msgSend() in a similar fashion. Change-Id: Ia93b2007ed8f263eaf99d604a3c88e857efbb421 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107257 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-05fix --disable-pdfium buildCaolán McNamara2-5/+8
Change-Id: I580972220bc39abe16288fa62c717e4ab25833d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105015 Tested-by: Jenkins Tested-by: René Engelhard <rene@debian.org> Reviewed-by: René Engelhard <rene@debian.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-12-05external/firebird: Fix checks for null HANDLE in Windows-only codeStephan Bergmann2-1/+46
Change-Id: I428bbdae91eaf69df43ae054a95e8da3fb1aa7dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107056 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-05Fix Firebird build on macOS on arm64Tor Lillqvist1-10/+12
Must set RAW_DEVICES_FLG=N for this architecture, too. Make the prefix.darwin_arm64 match the x86_64 one. Don't bother defining ARM64, just check for __aarch64__. Change-Id: I9de67493cb159ce97a46cdd1974b04753518c703 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106716 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-05New UBSan failures with Firebird 3.0.7Stephan Bergmann1-0/+20
While building ExternalProject_firebird: For one, the ICU UCHAR_TYPE mismatch > workdir/UnpackedTarball/firebird/src/intl/cs_icu.cpp:66:30: runtime error: call to function ucnv_fromUChars_68 through pointer to incorrect function type 'int (*)(UConverter *, char *, int, const unsigned short *, int, UErrorCode *)' from 61411db9f719d793f0665a4d278e0748e8fcd75f "external/firebird: ICU_UCHAR_TYPE breaks -fsanitize=function" returned in a slightly different form. Instead of passing in the problematic UCHAR_TYPE macro from external/firebird/ExternalProject_firebird.mk, Firebird now set it internally in src/common/common.h. And for another, it grew a new invalid-shift-base at > workdir/UnpackedTarball/firebird/src/yvalve/gds.cpp:2564:33: runtime error: left shift of negative value -1 (And beyond that there were no further new ASan/UBSan issues with a full `make check screenshot`.) Change-Id: Ie15cf6bde2df7dc784fec89045026f71747aa0bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106477 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-05firebird: update to 3.0.7Julien Nabet22-1366/+551
This tries to get rid of a lot of cruft from older builds and it also aims to build as much as possible on Windows. The firebird-cygwin-msvc-warnings.patch should be optional. It gets rid of various compiler warnings on Windows, either by disableing or fixing them: - fix: D9002 - ignoring unknown option '-fno-rtti' - fix: D9024 - unrecognized source file type <filename>, object file assumed - ign: C4291 - <declaration>: no matching operator delete found; memory will not be freed if initialization throws an exception - ign: C4477 - <function>: format string <string> requires an argument of type <type>, but variadic argument number has type <type> And I explicitly got rid of the "win32" handling and simply use arch depending patches on Windows, which strips additional stuff. sberg adds: I have no idea how in an upstream macOS build the empbuild executible in gen/examples should now find @rpath/lib/libfbclient.dylib, as it does not have an RPATH set. So add an appropriate one in external/firebird/firebird-macosx.patch.1's patch of builds/posix/Makefile.in.examples (which needs to know whether we do a Debug or a Release build; an attempt of using firebird's $(IsDeveloper) for that caused other failures, see bca0dc97bf3d1348c928bdaf4964524374835823 "Revert 'external/firebird: Pass --enable-developer into configure'", so use LO's $(ENABLE_DEBUG) and rely on that being exported from LO's make into firebird's make). Also, the fbclient and Engine12 dylibs now have RPATHs set which we do not need in LO (where we still stick to our general use of @loader_path), so drop them in external/firebird/ExternalProject_firebird.mk (even though leaving them in should be harmless). Change-Id: Id34bb88900d15f89adda03e34af2ac3d4f6aa085 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105440 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-05firebird: build fixes (incl. parallel build)Jan-Marek Glogowski8-105/+81
The main idea is to get rid of the "unset MAKEFLAGS". AFAI can see, the whole CPU stuff isn't used anymore. So we can drop the whole FB_CPU_ARG handling. Since LO doesn't use any of make's implicit rules, the build breaks, but luckily it just requires a single rule for the btyacc build - just a Firebuild build tool. Then there is the whole broken handling of LIBTOMMATH and LIBATOMIC_OPS already in LO's configure.ac. I don't know if any internal build of Firebird with these as system libs would work. I guess people either have a system Firebird or also build with internal libtommath and libatomic_ops. This fixes just the obvious errors. I didn't try to build it, so there might still be typos (TBH I thought hard about just dropping the system build of these libraries, after seeing the broken configure.ac). And I'm not sure our / the system boost preprocessor library is ever used over the Firebird-internal copy. It also looks like it's also just used in an other build tool and nothing of the Firebird DB itself depends on it. Then there is the movement of the install_name_tool / otool patching on MacOS from the patch into the ExternalProject to further shrink the patches, as the build doesn't depend on it. This also introduces a different debug build mode for the gcc-/g++-wrapper: MSVC_USE_INDIVIDUAL_PDBS. It uses -Fd to write a separate PDB per output file instead of using -FS to use sync writes to a single PDB, which might work around the PDB access failures seen by Jenkins for linking executables. In theory it's also faster and should work with all the other wrapper users, but I don't want to open that can of additional build errors (yet), for eventually marginal gains. Change-Id: I8d4c5d2f17def9e840a67ef1004787e8baaffa83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105902 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-12-05Make firebird build for macOS on arm64Tor Lillqvist2-0/+124
No idea whether it works. Change-Id: I008cf9fab56bedb2e1f33ad6a99c9cd95d7483a7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106024 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-05firebird: fix Thread handle type on WindowsJan-Marek Glogowski2-0/+38
MSVC compiler complains about 'warning C4312: "reinterpret_cast": conversion from "unsigned long" to "HANDLE" of greater size'. Seems like an real error, if real_handle is too small to hold the full "HANDLE" value, returned by _beginthreadex. Upstream strangely just fixed in master, not B3_0_Release branch. Change-Id: I87ad263529e119f68da976245646bf8b69efd35a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105924 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-12-05Modify the non-symlink libfbclient.dylib.3.0.0Stephan Bergmann1-1/+1
At least in my --enable-debug build, workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib originally contains libfbclient.dylib -> libfbclient.dylib.2 libfbclient.dylib.2 -> libfbclient.dylib.3.0.0 libfbclient.dylib.3.0.0 so if we modify libfbclient.dylib with install_name_tool, it will break the symlink and modify libfbclient.dylib but not libfbclient.dylib.3.0.0---where the latter is what gets delivered via external/firebird/ExternalPackage_firebird.mk. (This didn't cause any issues, though, because gb_LinkTarget__use_libfbembed in RepositoryExternal.mk links against the modified libfbclient.dylib in workdir, not against the delivered libfbclient.dylib.3.0.0, so e.g. Library_firebird_sdbc did already contain the correct @loader_path/libfbclient.dylib.3.0.0 reference. Also, the `install_name_tool -id` treatment of libEngine12.dylib in external/firebird/firebird-macosx.patch.1 should not technically be necessary, as nothing links against that library; but if left unmodified, it would record the build machine's /full-path-to/workdir/UnpackedTarball/firebird/gen/Debug/firebird/plugins/libEngine12.dylib so better "clean it up". Also, the `install_name_tool -change` treatment of libEngine12.dylib in external/firebird/firebird-macosx.patch.1 is necessary because otherwise it would record a full-path dependency to /full-path-to/workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.dylib.3.0.0 which macosx-change-install-names.pl, called from MAKE_POST in external/firebird/ExternalProject_firebird.mk, would not adjust. With all those modifications in external/firebird/firebird-macosx.patch.1, the call to macosx-change-install-names.pl should effectively have nothing left to do, as these libraries do not depend on any other LO-provided libraries, but better leave it in place anyway.) Change-Id: Icf7f2ff5cb844b07be223e0b74cd6a650725777a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-05Check first if there is such a "bin" directory before attempting to use itTor Lillqvist1-4/+6
In the test-install target in Makefile.in we remove the "bin" folder of the LibreOfficePython framework. Change-Id: Idf3d440c4f9465f21b5dcae60d4fc5ac21965dd8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106284 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106398 Tested-by: Jenkins
2020-12-05Allow --enable-macosx-sandbox without the codesigning identitiesTor Lillqvist2-5/+3
For cases where you just want "make test-install" to construct an app bundle that you will manipulate and then sign separately. Change-Id: Iad805618f74ec783ebc013a664f928511b388383 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106185 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106260 Tested-by: Jenkins
2020-12-05Drop Python modules we don't want on macOS, too, like on other platformsTor Lillqvist1-1/+19
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-05tdf#135479: Seems we need the more broad entitlement for Java's sakeTor Lillqvist1-1/+1
Sad, but OK. This reverts part of 2c366aae9263dc4115b054fe74b90cabea61fa0b. Change-Id: I6b74c871e3ec2408f833a5e2b652fd19cb7a2c0e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103230 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106994 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2020-12-05Make python3 build on macOS 11, including for arm64Tor Lillqvist2-0/+60
A combination of what is two separate commits in master. Change-Id: I92ac0c500388730eca0be4766f07b1af2d2808e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106471 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Make bridgetest exercise parameter passing in the C++/UNO bridge harderTor Lillqvist5-13/+126
The C++/UNO bridge for macOS on arm64 currently uses the Linux code. Apple's ABI uses slightly different parameter passing on the stack, though. See https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms?language=objc That has not been taken into account yet in the bridge code. The bridgetest, when run on macOS on arm64, didn't notice, sadly, but succeeded. With this change it crashes, as one would expect it to do. Add one more byte and short parameter to the setValues(), setValues2() and getValues() calls in the XBridgeTestBase interface. The stack allocation for those [in] parameters to setValues() differ between the Linux and Apple ABIs. Add corresponding attributes to the interface, and members to the SimpleTest struct. The changes to the source files in the cli subdirectory (C++/CLI, VB.NET, and C#) are done blindly as they aren't compiled even on Windows currently. Most likely the changes to them are incomplete and erroneous. Change-Id: I6f689a130d89b23cad9918829107d7da49a79c55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105770 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105888 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106470 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Cosmetic change to make it easier to see which parameter is the nthTor Lillqvist4-108/+277
Consequently put each parameter/argument on a separate line for the get/setValues methods. Will make it easier to add more parameters of such types and at such positions that they catch errors in the C++/UNO bridge on more platforms (specifically, the one for macOS on Apple Silicon). Change-Id: I68578d0401358317f3baf913ef4d53009c8f5f2f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105633 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105887 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106469 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Make --without-webdav work even with --enable-mpl-subsetTor Lillqvist1-1/+3
Change-Id: I319e0b3aefa721f2503494783af6d73470f592a2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105271 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106468 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Fix nss build for x86_64 on an Apple Silicon MacTor Lillqvist1-0/+3
Change-Id: I337f2a8e777394e586f659fadd819cf7dfc0a332 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104546 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106467 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05The config.{guess,sub} in $SRCDIR is good for external projects, tooTor Lillqvist3-3313/+1
No need for the older second copies in solenv/gbuild. Change-Id: I088f7d06b0727d1b336e3ba314b5c874d8ce3776 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103027 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106466 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Make the C++/UNO bridge work on macOS on arm64Tor Lillqvist9-13/+370
Use the same code as for Linux on aarch64, with minor additional hacks. (There are slight differences in the ABI. See https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html The run-time code generation requires use of a new API on macOS to work: See the use of pthread_jit_write_protect_np() in bridges/source/cpp_uno/shared/vtablefactory.cxx. Unlike the arm64 ABI used on Linux, on macOS (and iOS, but we don't really use the C++/UNO bridge for iOS) we need to pack parameters smaller than eight bytes according to their natural alignment. Bytes take one byte, shorts two bytes aligned at a two-byte boundary, etc. For some reason, when compiling for arm64-apple-macos, the symbols for the type_infos for the UNO exception types (_ZTIN3com3sun4star3uno16RuntimeExceptionE etc) end up as "weak private external" in the object file, as displayed by "nm -f darwin". We try to look them up with dlsym(), but that then fails. So use a gross hack: Introduce separate real variables that point to these typeinfos, and look up and dereference them instead. If this hack ends up needing to be permanent, instead of having a manually edited set of such pointer variables, we should teach codemaker to generate corresponding functions, and look up and invoke them to get the std::type_info pointer. When compiling for x86_64-apple-macos, the type_info symbols end up as "weak external" which is fine. (This is a combination of what was two patches in master.) Change-Id: I05f46a122a51ade1ac7dccd57cb90e594547740e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106465 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Use <alloca.h> for macOS and iOS, tooTor Lillqvist1-15/+1
Change-Id: I20f349cc03fe28536470c19f2559cc5414b823fb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100284 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106464 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Update config.{guess,sub} with latest versions and handle fallout of thatTor Lillqvist7-334/+432
From http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD . This time, do not apply the add-on change from 25a09c8776cc6088a5b2bf13dc84eb386c26bb7e to config.sub, but keep it pristine. Instead, let's start using the name "aarch64" instead of "arm64" for macOS and iOS in the autofoo context, as that is what those tools call it. Clang and Apple call it arm64, though. Change-Id: I1e05866c5fb08e0800cdfeaf7f6a71bfb43d1777 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100272 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106463 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Replace brittle gcc3_linux_aarch64 vtableSlotCall with pure assembler codeStephan Bergmann3-65/+75
* For one, as discussed in the comment at <https://gerrit.libreoffice.org/c/ core/+/91978/2#message-97da6c6ece7ae7bd49e9eb4843be333192fcc057> "Port to FreeBSD aarch64": "So it looks like Clang does not treat those register asm as we expect it would, at least on aarch64. "Witness a local Linux recent master --with-distro=LibreOfficeAndroidAarch64 [i.e., using Clang] build's > $ llvm-objdump --disassemble instdir/program/libgcc3_uno.a [...] > 0000000000000000 <vtableSlotCall>: > 0: ff 43 03 d1 sub sp, sp, #208 > 4: f4 4f 0b a9 stp x20, x19, [sp, #176] > 8: fd 7b 0c a9 stp x29, x30, [sp, #192] > c: fd 03 03 91 add x29, sp, #192 > 10: a8 43 00 91 add x8, x29, #16 > 14: bf 83 1d f8 stur xzr, [x29, #-40] > 18: e0 07 04 a9 stp x0, x1, [sp, #64] > 1c: e2 0f 05 a9 stp x2, x3, [sp, #80] > 20: e4 17 06 a9 stp x4, x5, [sp, #96] > 24: e6 1f 07 a9 stp x6, x7, [sp, #112] > 28: e0 07 00 6d stp d0, d1, [sp] > 2c: e2 0f 01 6d stp d2, d3, [sp, #16] > 30: e4 17 02 6d stp d4, d5, [sp, #32] > 34: e6 1f 03 6d stp d6, d7, [sp, #48] > 38: a8 03 1c f8 stur x8, [x29, #-64] > 3c: a0 43 5e b8 ldur w0, [x29, #-28] > 40: a1 03 5e b8 ldur w1, [x29, #-32] > 44: a5 83 5e f8 ldur x5, [x29, #-24] > 48: e4 03 08 aa mov x4, x8 > 4c: e2 03 01 91 add x2, sp, #64 > 50: e3 03 00 91 mov x3, sp > 54: f3 03 01 91 add x19, sp, #64 > 58: f4 03 00 91 mov x20, sp > 5c: 00 00 00 94 bl 0x5c <vtableSlotCall+0x5c> > 60: 60 06 40 a9 ldp x0, x1, [x19] > 64: 80 06 40 6d ldp d0, d1, [x20] > 68: 82 0e 41 6d ldp d2, d3, [x20, #16] > 6c: fd 7b 4c a9 ldp x29, x30, [sp, #192] > 70: f4 4f 4b a9 ldp x20, x19, [sp, #176] > 74: ff 43 03 91 add sp, sp, #208 > 78: c0 03 5f d6 ret [...] vs. [this commit's vtableslotcall.s; see below for details]. "And also latest Clang 12 trunk still does e.g. > $ cat test.c > void f(long); > void g() { > register long volatile a asm ("x8"); > f(a); > } > $ clang --target=unknown-linux-aarch64 -S -O2 test.c > $ cat test.s > .text > .file "test.c" > .globl g // -- Begin function g > .p2align 2 > .type g,@function > g: // @g > // %bb.0: // %entry > sub sp, sp, #16 // =16 > ldr x0, [sp, #8] > add sp, sp, #16 // =16 > b f > .Lfunc_end0: > .size g, .Lfunc_end0-g > // -- End function > .ident "clang version 12.0.0 (git@github.com:llvm/llvm-project eb31ddd71eb44d53ebe12a09c9587198bb6f2a2e)" > .section ".note.GNU-stack","",@progbits > .addrsig "(This is probably also the underlying issue that eb15ac837e06087fb8148330e9171d6697d89ee6 'android: Avoid throwing exceptions through the bridges' tries to hack arond.)" * For another, this also gets rid of the dddb527db1562f30a2a2b20338dfc8458086a4a9 "Again, no -fstack-protector-strong for gcc3_linux_aarch64/cpp2uno.cxx" hack. The contents of the new vtableslotcall.s is effectively the GCC 10 -S output of the old vtableSlotCall C++ function from cpp2uno.cxx. (And as cpp2uno.cxx only takes the address of vtableSlotCall, never calls it directly, it does not matter that it declares it with an imprecise extern "C" void vtableSlotCall(); signature.) Change-Id: Icfbf0622a47825ff7cf21008de27d3da6a2f0ebd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99660 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106460 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Avoid warning about deprecation in macOS 11.0Tor Lillqvist1-0/+3
Change-Id: Ie1a7e19093b439eb133632ee881e1e3dbe58132d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98176 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106459 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Avoid unused parameter 'pImpl'Tor Lillqvist1-4/+6
Change-Id: I8dd30ed3ffffa0e5340b32ce4399dd05cc57e2b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105962 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106258 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106457 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05There is no QuickTime frameworkTor Lillqvist1-1/+0
The reference was a leftover from 32-bit times. Change-Id: Ie453a4c644787a49f8742eab4b4ea9d49cddf32d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98175 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106456 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Initial attempt at macOS on arm64 support for OpenSSLTor Lillqvist3-0/+15
Sadly the existing arm64 assembler files in OpenSSL use a syntax that Apple's clang doesn't accept. And yeah, ideally we should not use either NSS or OpenSSL on macOS, but native APIs for the functionality in question. Trying to make everything look like Linux is a bone-headed approach. Change-Id: Ib3f137ac73329b92e82c654d1277ee21f5f81b37 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98095 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105871 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106371 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05More WIP work for macOS on Apple SiliconTor Lillqvist2-36/+5
If cross-compiling to a DESKTOP platform, use RepositoryModule_host.mk on the build platform, too. Change-Id: Icd3f3081e5af0c7cda95e9bce7572d37567d4f6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97356 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105869 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106369 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05For macOS on arm64, be sure to use HOST_PLATFORM=arm64-apple-darwinTor Lillqvist1-0/+5
(That is for external projects.) Change-Id: I709ff37ebca304f862ff94bdb1c6e6035f5cda77 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97981 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105870 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106370 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Fix apr build with current Xcode: Include <stdlib.h> for exit()Tor Lillqvist2-0/+27
(Or whatever it is that had broken it.) Change-Id: I72bc42e618f011518c05a2cdb875cfe64515b4d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105269 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106042 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106372 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Clean up arm64 confusion a bitTor Lillqvist1-2/+1
Set nss's CPU_ARCH to aarch64 also when compiling to arm64 on arm64, without any cross-compiling involved. Change-Id: I2eb9fb7b9547e5ded75ca242ea7ef09c826bf561 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106377 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Use USE_DLFCN also on macOS on arm64Tor Lillqvist1-0/+14
Change-Id: I8975ea2d4f33a101b5ac6db247a6dd062bc0c410 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100273 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106376 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Set CROSS_COMPILE=1 when cross-compiling nssTor Lillqvist1-0/+1
Change-Id: Iad826eb83e4c49078e6c668661446b5b70e6a981 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97987 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106375 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Be more generic for CPUNAME=ARM64Tor Lillqvist1-1/+2
It's used not just for iOS but can be macOS too. Also, nss wants to call it CPU_ARCH=aarch64. Change-Id: I6398c3bf1409f2ccf16b0d154ad7c2b56f493b15 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97986 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106374 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Use up-to-date config.{guess,sub} for external/nss, tooTor Lillqvist1-0/+2
Change-Id: I387aba22b90ab1bde1ae3659ea06a5838c1c829d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/97983 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106373 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Initial WIP steps for building for macOS on Apple SiliconTor Lillqvist4-41/+111
Don't use $host_os="darwin" for both macOS and iOS depending on $host_cpu. Soon macOS will run on either x86_64 or arm64. Instead, use "darwin" (or "macos") for macOS and "ios" for iOS. Some other early changes for arm64-apple-macos, too. Change-Id: Id89987d854ceba2cd87c6222db2081ccdec0c73e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96976 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105868 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106368 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-12-05Accept macOS SDK 11.0Tor Lillqvist1-4/+13
Change-Id: I92275eabe3c6a9442f675ec211c1dd1a8b58bd1b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96909 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105787 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106367 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-12-05Fix -Werror,-Wimplicit-function-declaration in posrgresql configuryTor Lillqvist2-0/+20
Includes the "Brown paper bag fix for e69f547bce7de376a0af464c5f7af5e7d2c8784a" Change-Id: I3c2dfb94a3c9627e802956cc03cebcbdb7d498cd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96912 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105499 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-12-05Add getopt declarationsTor Lillqvist2-0/+26
Avoids: implicit declaration of function 'getopt' is invalid in C99 [-Werror,-Wimplicit-function-declaration] on macOS with current Xcode. Change-Id: Ic178f53d1002425df52e220b1723fb12edca13df Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96910 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105498 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-12-05nss: restore manual pre-dependency buildJan-Marek Glogowski2-0/+84
We had some seldom build failures on Windows, with errors like: PermissionError: [WinError 32] The process cannot access the file because it is being used by another process: '..../nssckmdt.h'. This happens, because of the "." / parent shell hack. Thinking about it again, it doesn't prevent the parent make to run in parallel to the "." directory make. So I tried to use a terminal match-all rule like ifneq (,$(filter .,$(DIRS))) %:: # empty terminal rule triggered $(error can't happen) endif to stop the original parent make, but that doesn't work and the $(error ...) is triggered. So AFAIK I'm out of options here and have to restore the old manual pre-dependency build variant - still much better then no parallel build. An alternative idea was to put the rest of the rules.mk in the "else" of the terminal rule, to skip all normal rules, but this still leaves out all rules from the rest of the make-files, which might result in some hard to debug errors. This reverts my upstream patch 15608:744881490c78. Change-Id: I9e2e9e1ec9f35697c7853c92f60434f514cba5ab Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103777 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit d2f9c55e065d559de903d540da28502646714a24) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104881 Reviewed-by: Michael Stahl <michael.stahl@cib.de>
2020-10-21Version 7.0.3.1, tag libreoffice-7.0.3.1libreoffice-7.0.3.1Christian Lohmaier3-0/+0
2020-10-21bump product version to 7.0.3.1Christian Lohmaier1-1/+1
Change-Id: Ic80584b4390ddfe710d6aaa5d6ca1b37b52f9f04
2020-10-21Branch libreoffice-7-0-3Christian Lohmaier4-1/+1
This is 'libreoffice-7-0-3' - the stable branch for the 7.0.3 release. Only very safe changes, reviewed by three people are allowed. If you want to commit more complicated fix for the next 7.0.x release, please use the 'libreoffice-7-0' branch. If you want to build something cool, unstable, and risky, use master.
2020-10-21Update git submodulesChristian Lohmaier1-0/+0
* Update translations from branch 'libreoffice-7-0' to a032756b2ded48180d4db2996486c59d644bc6e3 - update translations for 7.0.2 rc2 and force-fix errors using pocheck Change-Id: Icc6c8d4e27bf80431ec26c8ceb37848058038c85
2020-10-21gitmodules: use relative pathsChristian Lohmaier1-3/+3
as using https://git.libreoffice.org breaks the submodule subsription (automatic update in core when something is pushed to the submodules), since gerrit compares the URL with gerrit.canonicalWebUrl, the URL where gerrit itself is found, not what is used as default repository URL Change-Id: I2e4566e69c7e70c463f0aab393d622a6f4d61808 (cherry picked from commit f7d892aa0b44772ccd70786375d3b6a4515af180)
2020-10-21tdf#137608 allow insert break to use a page number > 9999Caolán McNamara3-3/+3
writer is using sal_uInt16 for the page number. If we wanted anything bigger then the max possible sal_uInt16 then we would need to make real changes to writer to change the type. Leaving the type as sal_uInt16 but allowing 65535 then makes it real easy to use the ui to force writer to loop over to page 0 and I can predict the moaning about that. So I propose instead of an arbitrary max of 10000-1 to have an arbitrary max of 65535-10000 for 55535 instead. and use same max-page in textflow as insert, break and table-textflow too as well as para-textflow Change-Id: Id4c244e144f718c8917786cb9846625e4845b65a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104505 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2020-10-21Related: tdf#137250 need signal-changed for ComboBoxText tooCaolán McNamara1-1/+1
e.g. changing font in format, character with up/down/typeahead Change-Id: I2aabae8ea4108830bb5a0ca89ad694fe88a7444d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104301 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>