...found when building against LLVM 12 trunk libc++ on Linux
Change-Id: Iea8e623222940ed3d3e5830706a4538558ecf418
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100571
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...where all the Library_skia objects are built with Clang, so contain
intermediate LLVM bytecode, but were then linked via GCC and ld or gold, which
do not understand such object files and thus failed. So in
gb_LinkTarget__command_dynamiclink use T_CC/T_CXX also for the linker command
line. But then Clang would still be used for linking with the
-fuse-ld=(ld or gold)
$(USE_LD) suitable for GCC, and would still fail. So break T_USE_LD out of
T_LDFLAGS and let gb_LinkTarget_use_clang override T_USE_LD with CLANG_USE_LD.
At least for now, that CLANG_USE_LD (containing something like
-fuse-ld=lld
or
-fuse-ld=lld --ld-path=...
for the latter see d668c9a04d04d256fcbbd2165fe226f1db88256b "Adapt --enable-ld
to Clang 12 trunk --ld-path") needs to manually be passed into autogen.sh, it is
not computed in configure.ac.
Then building Library_skia would still fail to link against
StaticLibrary_libpng, as that only contains intermediate GCC object code, so
make sure to build it with -ffat-lto-objects in this specific case.
Change-Id: I0a104e53a8898cd9c2eb3b643e21954e853608cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100556
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
> cppuhelper/source/typemanager.cxx:1571:47: error: field 'entity_' is uninitialized when used here [-Werror,-Wuninitialized]
> ServiceBasedSingletonDescription_Base(entity_->isPublished()),
> ^
The code was like that ever since it was introduced in
fa559f1c416884015d1d83d0a7ac8803e745d9df "WIP: Experimental new binary type.rdb
format". Odd that that never caused an issue, but the code appears to at least
never be executed during `make check`.
Change-Id: I19fe78162c7c4a9211c380648595df9aa54bf4d7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100554
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
... to avoid crash accessing non-existing element of pChildItem->vIndices
Change-Id: I248a9301abd69883f940051d9d9671298dcc8453
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100540
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Fortunately, it is rather hard in Word to insert a nextColumn
section-break, so this situation is rarely seen,
and bug 135343's fix made it even more irrelevant.
The fix includes unit tests demonstrating this problem.
The column break should be inserted around m_xStartingRange,
but the section should start from pPrevSection->m_xStartingRange
and be extended include this section. But I have no idea
how to do that.
At least documenting that something is completely broken
should be very useful for anyone drawn to this code.
Change-Id: I878f99601bb2181500d215a0440a34a62f3840f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100461
Tested-by: Justin Luth <justin_luth@sil.org>
Reviewed-by: Justin Luth <justin_luth@sil.org>
The non-first lines start below the first one so the margin is already
included in the previous line's Y position.
Also move the testTdf116486 to layout.cxx.
(regression from d07fc485d46f431405a3f6a002f951a08c559677)
Change-Id: I574516ea5f9600e2d861e43162b1a69488c68819
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100440
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
a) The unit tests are about charts and therefore it is more natural to
have them in module chart2.
b) The file name of the chart in the pptx package is generated with a
static counter. Therefore the name depends on whether there have
been previous savings. Module chart2 has a method, that ignores the
number and takes the first matching file. Using that makes the tests
more stable and allows to fix the static counter without need to
adjust the tests.
c) I have put them into a new test suite, which I have started
recently. The other test suites are already hudge.
So this patch depends on commit
74be8bb787a44464957e5d3105c8de6d36e81b4a
d) I have made the paths in the tests independent of the naming
conventions which LibreOffice uses for styles and definitions.
e) I have split the tests in export and import.
Change-Id: If68c6e8d1eea8470074b96fb2c9efdd9090264b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100451
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
The crash problem in MacOS and Windows is fixed.
Change-Id: I2968880b77f723f2caf6dc77f4904411392c4008
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100449
Tested-by: Jenkins
Reviewed-by: Muhammet Kara <muhammet.kara@collabora.com>
The welded sidebar contains only controls with officecfg based
registration. Such controls are created by the service manager,
which already calls the initialize method on its own, so there
is no point in doing it again. This code was copy-pasted from
the vcl based sidebar code path, but there it is guarded by a
condition to not apply to such controls since commit 2c1d6e59
("tdf#103624 Avoid double init of controls in SidebarToolBox").
Change-Id: I926f67f65b78799b6c3929184010be8af495817f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100448
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
Problem can be seen when experimental features turned off and
Groupedbar Compact is active, but its menu item isn't checked.
Change-Id: I0386fccd0f64cde678c78d9f15dd853a6247e3ab
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100446
Tested-by: Jenkins
Reviewed-by: Maxim Monastirsky <momonasmon@gmail.com>
...as seen during UITest_writer_tests2:
> ==2548829==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b0002be9d0 at pc 0x7f42be5ddc7f bp 0x7ffe2d26b090 sp 0x7ffe2d26b088
> READ of size 1 at 0x60b0002be9d0 thread T0
> #0 in cppu::WeakComponentImplHelperBase::release() at cppuhelper/source/implbase.cxx:84:9
> #1 in cppu::PartialWeakComponentImplHelper<com::sun:⭐:lang::XServiceInfo, com::sun:⭐🫘:XPropertySetInfo>::release() at include/cppuhelper/compbase.hxx:86:36
> #2 in rtl::Reference<UcbPropertiesManager>::~Reference() at include/rtl/ref.hxx:113:22
> #3 in __run_exit_handlers at /usr/src/debug/glibc-2.31-48-g64246fccaf/stdlib/exit.c:108:8
> #4 in exit at /usr/src/debug/glibc-2.31-48-g64246fccaf/stdlib/exit.c:139:3
> #5 in __libc_start_main at /usr/src/debug/glibc-2.31-48-g64246fccaf/csu/../csu/libc-start.c:342:3
> 0x60b0002be9d0 is located 64 bytes inside of 112-byte region [0x60b0002be990,0x60b0002bea00)
> freed by thread T0 here:
> #0 in free at /home/sbergman/github.com/llvm/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:123:3
> #1 in rtl_freeMemory at sal/rtl/alloc_global.cxx:51:5
> #2 in cppu::WeakComponentImplHelperBase::operator delete(void*) at include/cppuhelper/compbase_ex.hxx:66:11
> #3 in UcbPropertiesManager::~UcbPropertiesManager() at ucb/source/core/ucbprops.cxx:197:1
> #4 in cppu::OWeakObject::release() at cppuhelper/source/weak.cxx:233:9
> #5 in cppu::WeakComponentImplHelperBase::release() at cppuhelper/source/implbase.cxx:86:18
> #6 in cppu::PartialWeakComponentImplHelper<com::sun:⭐:lang::XServiceInfo, com::sun:⭐🫘:XPropertySetInfo>::release() at include/cppuhelper/compbase.hxx:86:36
> #7 in rtl::Reference<UcbPropertiesManager>::clear() at include/rtl/ref.hxx:180:19
> #8 in UcbPropertiesManager::dispose() at ucb/source/core/ucbprops.cxx:205:16
> #9 in cppu::WeakComponentImplHelperBase::release() at cppuhelper/source/implbase.cxx:79:13
> #10 in cppu::PartialWeakComponentImplHelper<com::sun:⭐:lang::XServiceInfo, com::sun:⭐🫘:XPropertySetInfo>::release() at include/cppuhelper/compbase.hxx:86:36
> #11 in rtl::Reference<UcbPropertiesManager>::~Reference() at include/rtl/ref.hxx:113:22
> #12 in __run_exit_handlers at /usr/src/debug/glibc-2.31-48-g64246fccaf/stdlib/exit.c:108:8
The elaborate g_Instance disposal scheme had been introduced with
3d44c6a49b20415616dab7a2de2820da5efab309 "ucb/core: create instances with uno
constructors", but it is unclear to me for what reason.
Change-Id: I768bc3a8674e0e81cf89adae58e4a67d14509985
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100456
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Use the same code as for Linux on aarch64, with minor
additional hacks. But that will not actually work in all cases, as
there are slight differences in the ABI. See
https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
Thus we can drop the use of the lo_mobile_throwException() hack that
was very temporarily used.
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.
For some reason, with the Xcode 12 betas, 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.
With this, LibreOffice starts and seems to work to some extent, and
many unit tests succeed.
Change-Id: I05f46a122a51ade1ac7dccd57cb90e594547740e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100408
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
...in UnpackedTarball/mariadb-connector-c/libmariadb/bmove_upp and in
workdir/UnpackedTarball/mariadb-connector-c/libmariadb/ma_stmt_codec.c. Given
that the first of the two contains nothing but that redundant declaration, lets
drop it from the (hand-curated?) list of included source files.
(I came across this when experimenting with --enable-lto on Linux and
temporarily including static libraries as --whole-archive, which thus caused a
"multiple definition" error when linking StaticLibrary_mariadb-connector-c into
Library_mysqlc.)
Change-Id: I8c5f4de476a4bbd036fd25940cdb44d11954ecc8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100427
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Redist is a system component, that includes a varying set of DLLs,
and those DLLs are ref-counted. Installing a newer redist - i.e.
updating and increasing refcount of existing DLLs - may add new
DLLs (with initial refcount 1) in addition to the updated old DLLs
that start depending on the newly added ones; at uninstall, the
newly added DLLs may get removed because their refcount gets 0,
while other redist DLLs are kept at the updated levels - so their
dependencies now are not met, and redist gets broken.
Just mark the redist components permanent, which, according to [1],
"registers an extra system client for the component in the Windows
Installer registry settings".
A downside is that uninstall doesn't restore the original system
state ideally.
[1] https://docs.microsoft.com/en-us/windows/win32/msi/component-table
Change-Id: I3fe82bcb5844f826f5b1df622273b4e3a1e3c436
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100426
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
