summaryrefslogtreecommitdiff
path: root/qadevOOo/tests
ModeNameSize
d---------java60logplain
generated by cgit (git 2.34.1) at 2025-01-11 12:47:24 +0000
ion'>Stephan Bergmann That flag is only supported by clang-cl, not by MSVC, and c7c9f3f57a2feae5d3bc3c47104786883ed09e44 "use clang-cl's -Zc:dllexportInlines- for clang-cl builds" apparently naively assumed that it would work to build LO with clang-cl and that flag without actually trying it out, and 1040228c356d75c5228cde4d6103f9b446848e4b "My clang-cl build does not work with -Zc:dllexportInlines-" effectively disabled it completely. The way to avoid unresolved external symbols during linking of URE libraries (see the 1040228c356d75c5228cde4d6103f9b446848e4b commit message) is apparently to also build libraries that the URE libraries depend on with the flag, hence the change from gb_Library_set_is_ure_library to gb_Library_set_is_ure_library_or_dependency. For now, I only marked those additional libraries (unoil and xmlreader) that actually caused issues when linking the URE libraries. Change-Id: I3a85c73246250981cd86b7ee41f87b41f393a4b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126012 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins 2021-09-28Warn harder about unknown constructors and factories on iOS in XcodeTor Lillqvist Use NSLog() and not just SAL_WARN(). There are so many irrelevant SAL_WARN() warnings displayed that these ones that can be extremely relevant are easily missed. I typically run the app in Xcode with SAL_LOG=-WARN. (Such warnings are typically caused by something missing from the solenv/bin/native-code.py.) Change-Id: I4ab16f4f652ac34319021c9427e2e9f911ee29e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122721 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122756 Tested-by: Jenkins 2021-09-20use MSVC's /Zc:inline option to reduce binary sizeLuboš Luňák If I'm getting it right, MSVC has a non-conforming feature that allows to declare a function as inline without defining its body in the header, and it'll work if the function is actually emitted elsewhere, and the linker will sort it out. This seems to be implemented by forcing emitting of out-of-line copies of all inline functions, which is wasteful. /Zc:inline disables this useless feature, which seems to save quite some space (optimized build, starmath's .o files 350k->220k, smlo.dll 2.5M->2.2M). The docs don't say anything about binary compatibility, but treat it the same way as -Zc:dllexportInlines, just in case. This change also may help avoid the tdf#144598 problem for our AVX/etc. code, such as in Calc. Change-Id: I73cc5d46ba1e4245e8d3b6688804c2b9684d2f9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122334 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2021-09-20use clang-cl's -Zc:dllexportInlines- for clang-cl buildsLuboš Luňák This is clang-cl's equivalent of -fvisibility-inlines-hidden, and it seems to be also sort of the equivalent of MSVC's -Zc:inline. So it saves build time and disk space. Clang docs say that this is binary compatible in only one direction, so our public C++ code shouldn't be using this, as external C++ code could try to use exported inlines that are no longer there. Change-Id: Ie6217808f8ee4a15344183abfc65038e1558d1b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122352 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-12-05android: Avoid throwing exceptions through the bridges.Jan Holesovsky From some reason it does not work, so let's do the same we are doing on iOS; at least for now. Change-Id: I915f8683a112548fc3defc1114f9dce3aa7be30e Reviewed-on: https://gerrit.libreoffice.org/84067 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/84204 Tested-by: Jenkins Reviewed-by: Jan Holesovsky <kendy@collabora.com> 2019-09-23do not require $(SRCDIR) in every gb_Library_set_precompiled_headerLuboš Luňák Change-Id: I7b3a22584bb2e4d501f509ffcd80929feed23a4c Reviewed-on: https://gerrit.libreoffice.org/79360 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>