Age | Commit message (Collapse) | Author |
|
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
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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>
|
|
...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>
|
|
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>
|
|
...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>
|
|
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>
|
|
Change-Id: Ia388bc2167925a29c1984920b6913f41611c3073
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107142
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
Change-Id: I428bbdae91eaf69df43ae054a95e8da3fb1aa7dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107056
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
They were already compiled in some way.
Change-Id: Ic1b8563a53bad5be03bce2c0d3d2cf841e303f02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107007
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
... and remove dialog authentication plugin; it quite uselessly defaults
to asking for a password on stdin, unless a function symbol is defined
by the library that links the connector static library.
There are more authentication plugins but no idea if those are needed.
Change-Id: I88ee9629e4763fb548c3f294b552cff3d739e6cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107006
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
That seems to happen in a sandboxed process on macOS, at least. This
caused an apparent hang when invoking Python, for instance simply
through Tools > Macros > Run Macro... .
Change-Id: I6bc055b44f298251ed596084538b98442c215fce
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107013
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
...that happen when building ExternalProject_python3 itself after
12142490cd43f8568ab29e0ddfa75b334d6d39d5 "Enable Python Py_DEBUG setting when
built with --enable-dbgutil on Linux":
For one, silence
> Modules/posixmodule.c:14395:9: runtime error: left shift of 34 by 26 places cannot be represented in type 'int'
> #0 in all_ins at workdir/UnpackedTarball/python3/./Modules/posixmodule.c:14395:9
where at least my kernel-headers-5.9.9-200.fc33.x86_64
/usr/include/linux/memfd.h has
> #define MFD_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB
and /usr/include/asm-generic/hugetlb_encode.h has
> #define HUGETLB_FLAG_ENCODE_16GB (34 << HUGETLB_FLAG_ENCODE_SHIFT)
For another (and as predicted in 29d47d22c43e6adc1850b7db5880028dcd07d1b3 "Fix
passing --disable-optimized into external/python3": "in a Linux UBsan build,
making ExternalProject_python3 would have started to cause some 'applying zero
offset to null pointer' failures, but which would have been easy to fix"),
silence
> Objects/listobject.c:551:24: runtime error: applying zero offset to null pointer
> #0 in list_concat at workdir/UnpackedTarball/python3/Objects/listobject.c:551:24
Change-Id: I0523cd35e393000c8e67629a0522b2db1d8c16f0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106984
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This has been suggested on IRC for testing fixes/avoiding regressions
when working on the GIL locking in PyUNO.
Change-Id: Ifda21a867b3c0c7db636a9ec950050012e4742de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106791
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Jenkins
|
|
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>
|
|
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>
|
|
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>
|
|
This reverts commit 823059c8f046927c3193da5acd78053f3269b753. It was meant as a
prerequisite for a macOS-specific fix in patch set 19 of
<https://gerrit.libreoffice.org/c/core/+/105440/19> "firebird: update to 3.0.7",
but caused both the Jenkins Windows build of that Gerrit change's patch set, as
well as vmiklos' Linux build based on 823059c8f046927c3193da5acd78053f3269b753
to fail with "Could not find acceptable ICU library" messages. The reasons have
not been tracked down, but are presumably because
workdir/UnpackedTarball/firebird/gen/Makefile starts to execute some more recipe
lines based on IsDeveloper being "Y". Lets seek another fix for the macOS issue
instead.
Change-Id: I4bd6ad38bc0fc0ef2debd5ef55131bccbff54ebc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106675
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...instead of merely forcing the Make target to Debug. That way, a future
patch set of in-progress <https://gerrit.libreoffice.org/c/core/+/105440/16>
"firebird: update to 3.0.7" will be able to know in the gen/examples sub-
directory Make that the top-level Make was targeting Debug, not Release. (Which
it will presumably need to know to fix the macOS build.)
Change-Id: I57f90f66b4739b9d2cb5c33d79fcb87090c820bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106588
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
due to an out of bounds array access in
raptor_xml_writer_start_element_common
use a better fix than the initial suggestion
See:
https: //bugs.mageia.org/show_bug.cgi?id=27605
https: //www.openwall.com/lists/oss-security/2020/11/13/1
Change-Id: I9203904755b0e4ac98ae1e39942fd6f616c1efff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106488
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
due to an out of bounds array access in
raptor_xml_writer_start_element_common
See:
https://bugs.mageia.org/show_bug.cgi?id=27605
https://www.openwall.com/lists/oss-security/2020/11/13/1
Change-Id: Ida4783a61412ffce868eacf81310da338d3e2df1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106423
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Add pvio_npipe + pvio_shmem + dialog
Change-Id: I48d828e5cdf8d269aef3a40d75235a9519af8dc1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105804
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: Id62a688d2ddf7493d419a00a9fd0dfc6a6f13f0c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106173
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: If304aa6be018442a72e284f62d7745b3cdaef536
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105668
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
...in vcl:
> [GAL] sounds
> instdir/program/gengal.bin: symbol lookup error: instdir/program/libvcllo.so: undefined symbol: _ZTI14GrContext_Base
> make[1]: *** [solenv/gbuild/Gallery.mk:56: workdir/Gallery/sounds.done] Error 1
(I didn't check what source exactly causes UBSan to require it now.)
Marking both the class and some of its members as SK_API would cause MSVC to
fail with
> error: attribute 'dllexport' cannot be applied to member of 'dllexport' class
so remove it from the class members.
Change-Id: I9f5ed397d32f1f445bfa1d70bcff494e78c16046
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106039
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...seen when e.g. building CustomTarget/i18npool/breakiterator/char_in.brk:
> rbbitblb.cpp:1405:18: runtime error: member access within misaligned address 0x627000026987 for type 'icu_68::RBBIStateTableRow', which requires 2 byte alignment
> 0x627000026987: note: pointer points here
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^
and
> rbbitblb.cpp:1607:18: runtime error: member access within misaligned address 0x627000026ecf for type 'icu_68::RBBIStateTableRow', which requires 2 byte alignment
> 0x627000026ecf: note: pointer points here
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^
(i.e., even though those code branches only access the byte-sized
RBBIStateTableRow8 data, they did so through a RBBIStateTableRow union pointer,
which has stronger alignment requirements)
Change-Id: I0abe5bd756758e33e495538f548e80f99460f43c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/106038
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
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>
|
|
Also made it necessary to adapt two places in libcdr and libebook
that used UBool TRUE which is gone now to use standard true
instead.
Change-Id: I1c1df3030f8b883bec6045756907ee0b78060382
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105964
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.com>
|
|
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>
|
|
Change-Id: I74c19597b07e9d07ee90e4191b75787241fdd845
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105829
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
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>
|
|
Change-Id: I6716048f0b58eb502b9d1ade8a13b8e33e4aaf2b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105905
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
There is no /usr/lib/libz.dylib any longer in macOS 11.
No idea whether it works (especially on arm64), but that is another
issue.
Change-Id: I92ac0c500388730eca0be4766f07b1af2d2808e0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105897
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
All the needed API is already in the version we bundle, except one. And
also we'll need direct access to the underling pdfium document, for now.
Change-Id: Ib5c87c95072401b1a6ca0151177d70b4bcd8c46d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105610
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
see the linked
<https://lists.gnu.org/archive/html/autoconf/2020-11/msg00004.html> "Fallout
from _AC_UNDECLARED_WARNING in autoconf 2.70beta" for details
Change-Id: I02c0f41d8f9e2ec7f833423a55ccbfff19e5ceb8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105555
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Old make thinks that ; terminates the recipe, have to escape it.
(other changes are just cosmetic)
(regression from 8c9b8c5970a08c2ef0ccddb7a691f3731d39175a)
Change-Id: Ib0119511977bbff077f037fbb5975df9f860ae58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105516
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
Change-Id: I7552b65022b725c6e87fef61478dc6e9c4322559
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105376
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
|
|
...as now reported when building with recent trunk GCC/libstdc++ on Linux:
> In file included from WPXContentListener.cpp:26:
> In file included from ./WPXContentListener.h:29:
> ./WPXTable.h:56:31: error: unknown type name 'size_t'; did you mean 'std::size_t'?
> const WPXTableCell *getCell(size_t i, size_t j)
> ^~~~~~
> std::size_t
Change-Id: Ic20240f01c7b0305cb87ababf53a3aaf66072d61
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105324
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
(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>
|
|
Change-Id: Ic10cf99fa412f8f0b3475e82d0a1839a7f04bd08
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105272
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
...seen when opening an Impress presentation on GNOME/X11:
> cairo-xlib-source.c:570:26: runtime error: left shift of 191 by 24 places cannot be represented in type 'int'
> cairo-xlib-render-compositor.c:1852:17: runtime error: left shift of negative value -186
> cairo-xlib-render-compositor.c:1853:17: runtime error: left shift of negative value -646
> cairo-xlib-surface-shm.c:1157:43: runtime error: member access within null pointer of type 'cairo_xlib_shm_surface_t' (aka 'struct _cairo_xlib_shm_surface')
> cairo-fixed-private.h:252:8: runtime error: left shift of negative value -146048
Change-Id: I93a5706c2ec3f83bc56d75fc92817668eef57fdb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105074
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
> pixman-utils.c:217:14: runtime error: left shift of 155 by 24 places cannot be represented in type 'int'
...which happened once while using the LO GUI
Change-Id: I174a29e240f09576859308ada56fe240881f0dad
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104915
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
A full `make check screenshot` required lots of little "harmless" fixes in
pixman and cairo to address:
> cairo-image-compositor.c:133:34: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
during CppunitTest_emfio_emf
> pixman-fast-path.c:3089:23: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
during CppunitTest_emfio_emf
> pixman-sse2.c:5019:17: runtime error: load of misaligned address 0x7f99303dbac5 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during CppunitTest_emfio_emf
> cairo-fixed-private.h:64:14: runtime error: left shift of negative value -8388608
during CppunitTest_emfio_wmf
> pixman-sse2.c:6443:20: runtime error: left shift of 198 by 24 places cannot be represented in type 'int'
during CppunitTest_filter_svg
> pixman-sse2.c:5976:6: runtime error: load of misaligned address 0x629000163202 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during CppunitTest_filter_svg
> pixman-sse2.c:3259:10: runtime error: load of misaligned address 0x606000c85761 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during CppunitTest_oox_vml
> pixman-sse2.c:521:18: runtime error: load of misaligned address 0x607000ca9d41 for type 'const uint32_t' (aka 'const unsigned int'), which requires 4 byte alignment
during CppunitTest_oox_vml
> pixman-gradient-walker.c:196:14: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
during CppunitTest_sc_tiledrendering
> pixman-combine32.c:786:1: runtime error: left shift of 255 by 24 places cannot be represented in type 'int32_t' (aka 'int')
during CppunitTest_vcl_backend_test
> pixman-fast-path.c:2761:29: runtime error: left shift of negative value -99
during CppunitTest_xmloff_draw
> pixman-bits-image.c:243:31: runtime error: left shift of negative value -99
during CppunitTest_xmloff_draw
> pixman-bits-image.c:244:31: runtime error: left shift of negative value -9
during CppunitTest_sd_tiledrendering
> pixman-fast-path.c:2762:29: runtime error: left shift of negative value -84
during CppunitTest_sw_rtfexport2
> cairo-gstate.c:2300:14: runtime error: null pointer passed as argument 1, which is declared to never be null
during CppunitTest_sw_ooxmlexport8
> pixman-access.c:389:2: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
during CppunitTest_sw_ooxmlexport15
> ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ff264ae275c at pc 0x7ff238941795 bp 0x7fff6bbadb10 sp 0x7fff6bbadb08
> READ of size 4 at 0x7ff264ae275c thread T0
> #0 in _add_clipped_edge at workdir/UnpackedTarball/cairo/src/cairo-polygon.c:351:24 (instdir/program/libcairo.so.2 +0x88c794)
during CppunitTest_sw_odfexport
> cairo-tor-scan-converter.c:1619:34: runtime error: left shift of negative value -39
during CppunitTest_sw_odfexport
> ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fe6ca085750 at pc 0x000000325c3a bp 0x7fff899bedd0 sp 0x7fff899be580
> READ of size 16 at 0x7fe6ca085750 thread T0
> #0 in __asan_memcpy at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 (workdir/LinkTarget/Executable/cppunittester +0x325c39)
during CppunitTest_sw_odfexport
> pixman-sse2.c:3352:14: runtime error: left shift of 65535 by 16 places cannot be represented in type 'int'
during CppunitTest_sw_odfexport
> cairo-gstate.c:2355:14: runtime error: null pointer passed as argument 1, which is declared to never be null
during CppunitTest_basctl_dialogs_test
> pixman-sse2.c:3537:10: runtime error: load of misaligned address 0x615000167682 for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during CppunitTest_sc_screenshots
> cairo-image-source.c:512:10: runtime error: load of misaligned address 0x6180037aee6f for type 'uint32_t' (aka 'unsigned int'), which requires 4 byte alignment
during UITest_writer_tests7
Change-Id: Icd2a211df4751d8dbfd5903bfba424b4c4672999
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104572
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
I had managed to break it with 92b99bddb63b1bf4a639fc969727ac35b3ed1ac8
that made it possible to build for (Rosettafied) x86_64 on an Apple
Silicon Mac.
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>
|
|
Change-Id: I3e596254b2e4ecc9f56ff09eeb63b66195ea6a2e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104376
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Clang's scan-build tool uses the CLANG_CXX environment variable (setting it up
in the scan-build script to pass it to the ccc-analyzer script), but happens to
erroneously set it to a non-existing path (see <https://reviews.llvm.org/D89481>
"[scan-build] Fix clang++ pathname again"). So wrapping LO's autogen.sh and
make in scan-build picked up that broken CLANG_CXX and caused build
failures like
> [CXX] external/skia/source/SkMemory_malloc.cxx
> /bin/sh: ~/llvm/inst/bin/clang-12++: No such file or directory
(see
<https://lists.freedesktop.org/archives/libreoffice/2020-October/086113.html>
"Re: llvm/clang static analyzer reports").
So rename CLANG_CXX, and for consistency also CLANG_CC and the various
CLANG_CXXFLAGS_INTRINSICS_*, by prefixing each with LO_.
Change-Id: Ib41cabe940f8bfb1997f74e865cca5725f859e07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104383
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|