New branch 'private/tml/lov-7.0.4' available with the following commits:
commit 9863c8d8e7b3cc01b1383a6c937f88aa4517920f
Author: Tor Lillqvist <t...@iki.fi>
Date: Sun Dec 6 18:43:10 2020 +0200
More NSS fixes for macOS on arm64
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 <t...@collabora.com>
commit d0aaf0933fef8fbb91e62a6ee5c221462530a564
Author: Tor Lillqvist <t...@iki.fi>
Date: Sat Dec 5 18:16:37 2020 +0200
Remove remaining bogus use of objc_msgSend()
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 <t...@collabora.com>
commit 5dc5a0c362788d265aadde77f855306e7c07fc7a
Author: Tor Lillqvist <t...@iki.fi>
Date: Sat Dec 5 17:25:30 2020 +0200
Fix crash or hang on macOS on arm64 when opening a file picker
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 <t...@collabora.com>
commit 22da09f764a9df524207df0bbb2a274f9924fd58
Author: Stephan Bergmann <sberg...@redhat.com>
Date: Wed Dec 2 11:14:19 2020 +0100
external/firebird: Fix checks for null HANDLE in Windows-only code
Change-Id: I428bbdae91eaf69df43ae054a95e8da3fb1aa7dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107056
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sberg...@redhat.com>
commit ac3ba63c876c364c3bdfb8fc1c39b80a890f8cea
Author: Tor Lillqvist <t...@iki.fi>
Date: Fri Nov 27 00:41:00 2020 +0200
Fix Firebird build on macOS on arm64
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 <t...@collabora.com>
commit 12464a04ae5090402ec3e88763ff65075c7ae96d
Author: Stephan Bergmann <sberg...@redhat.com>
Date: Tue Nov 24 08:22:51 2020 +0100
New UBSan failures with Firebird 3.0.7
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 <sberg...@redhat.com>
commit 70c79929dd2fd851aedcf162284cb495db277a83
Author: Julien Nabet <serval2...@yahoo.fr>
Date: Fri Nov 13 18:45:29 2020 +0100
firebird: update to 3.0.7
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 <sberg...@redhat.com>
commit a27ac3e9ea321bceeddf5704724ebf69277058ca
Author: Jan-Marek Glogowski <glo...@fbihome.de>
Date: Sun Nov 15 19:57:48 2020 +0100
firebird: build fixes (incl. parallel build)
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 <glo...@fbihome.de>
commit 5d6676b9e3a2152766fe4022991bec8042dc438e
Author: Tor Lillqvist <t...@collabora.com>
Date: Mon Nov 16 19:29:04 2020 +0000
Make firebird build for macOS on arm64
No idea whether it works.
Change-Id: I008cf9fab56bedb2e1f33ad6a99c9cd95d7483a7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106024
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <t...@collabora.com>
commit 0be47835f27b87fc69cb993e61859558fb98754b
Author: Stephan Bergmann <sberg...@redhat.com>
Date: Mon Nov 16 15:22:55 2020 +0100
Modify the non-symlink libfbclient.dylib.3.0.0
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 <sberg...@redhat.com>
commit b8f5b5ca09d4282c75260bce4940cc4aec55a2ab
Author: Tor Lillqvist <t...@collabora.com>
Date: Fri Nov 20 01:02:02 2020 +0200
Check first if there is such a "bin" directory before attempting to use it
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 <jenkinscollaboraoff...@gmail.com>
Reviewed-by: Tor Lillqvist <t...@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106398
Tested-by: Jenkins
commit 955f15cb2b4b3843b35cea00c008e7735ed5d1fe
Author: Tor Lillqvist <t...@collabora.com>
Date: Thu Nov 19 22:04:21 2020 +0200
Allow --enable-macosx-sandbox without the codesigning identities
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 <jenkinscollaboraoff...@gmail.com>
Reviewed-by: Tor Lillqvist <t...@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106260
Tested-by: Jenkins
commit 5f5008362381069851c403e94f6158dbed6bee7f
Author: Tor Lillqvist <t...@collabora.com>
Date: Wed Dec 2 12:21:36 2020 +0200
Drop Python modules we don't want on macOS, too, like on other platforms
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 <jenkinscollaboraoff...@gmail.com>
Reviewed-by: Tor Lillqvist <t...@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107141
Tested-by: Tor Lillqvist <t...@collabora.com>
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
