Age | Commit message (Collapse) | Author |
|
It was replaced by ZXing library.
Change-Id: I49eb809586c7b4ba3a93fd77f804bfc93fead669
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112701
Reviewed-by: René Engelhard <rene@debian.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I0023f6ce8315427b1a3deaf755e78ae06475b08c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112053
Reviewed-by: René Engelhard <rene@debian.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Tested-by: René Engelhard <rene@debian.org>
Tested-by: Jenkins
|
|
And check that LIB_FUZZING_ENGINE is set during configure.
Because:
1. It's easier to build locally this way (you don't need to build or hack a
libFuzzingEngine.a - instead you can just specify
LIB_FUZZING_ENGINE=-fsanitize=fuzzer to produce a valid build).
2. Using -lFuzzingEngine is deprecated [1] for various reasons [2].
The old behaviour can be emulated if desired by setting
LIB_FUZZING_ENGINE=-lFuzzingEngine .
This patch was tested as follows:
- Building LO within oss-fuzz via:
python infra/helper.py build_fuzzers --sanitizer address libreoffice </path/to/patched-libreoffice-core>
python infra/helper.py check_build libreoffice
- Building LO fuzzers standalone via:
export CC="clang-11"
export CXX="clang++-11 -stdlib=libc++"
export CFLAGS="-fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION"
export CXXFLAGS="$CFLAGS -stdlib=libc++"
export LDFLAGS="$CFLAGS -Wl,--compress-debug-sections,zlib -lpthread"
export LIB_FUZZING_ENGINE=-fsanitize=fuzzer
./autogen.sh --with-distro=LibreOfficeOssFuzz --with-system-libxml
make fuzzers
(--with-system-libxml only appears to be needed because of issues
specific to my build environment/Suse 15.2. I'm invoking clang-11 simply
because that's the most modern clang I have installed, plain clang should
also work on most sufficiently modern systems).
[1]
https://github.com/google/oss-fuzz/blob/481280c65048fd12fb2141b9225af511a9ef7ed2/infra/presubmit.py#L46
[2] https://github.com/google/oss-fuzz/issues/2164
Change-Id: Iddb577c30a39620e72372ef6c2d3fda67f8aabdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111691
Tested-by: Jenkins
Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
...given that <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296#c5>
"[8/9/10/11 Regression] -Wstringop-overflow false positive due to using MEM_REF
type of &MEM" is declared fixed now on GCC 11 trunk.
(Moving -Wno-stringop-overflow from gb_CFLAGS_WERROR to gb_CXXFLAGS_COMMON is
done for no other reason than to harmonize this with the code for the similar
HAVE_BROKEN_GCC_WMAYBE_UNINITIALIZED.)
Change-Id: I3468138c9bbda28f754d4162cb9c059796bd3932
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111029
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
However considering git history about vlc part (see
https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=vlc) it seems
there's no real patch since 2013 + it's been explicitely indicated as
experimental since 2015
See http://document-foundation-mail-archive.969070.n3.nabble.com/About-vcl-status-in-avmedia-keep-or-removed-unmaintained-code-since-7-years-tt4293282.html
Of course if someone wants to keep on the work on it, it's always possible to revert the patch.
Change-Id: Ia1602ea61b7ffa577148a80f974ebdcb71495fbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108283
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I21b8055fc97d8dfb8429e7dafa1a3982c3b7499b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108122
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
The SDK's <https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/
Transparent_Use_of_Office_UNO_Components> on all platforms included the Windows-
specific unowinreg.dll in generated jars (so that those jars, when distributed
to a Windows environment, would find a LO installation by inspecting the Windows
registry). That unowinreg.dll was originally built as a 32-bit DLL (though when
building a 64-bit Windows LO, it happened to be built as a 64-bit DLL). For
non-Windows LO builds, it could either be built locally with a MinGW toolchain
(--enable-build-unowinreg) or downloaded from dev-www.libreoffice.org.
However, that had various issues:
For one, unowinreg.dll was not necessarily available in a distributed jar as a
64-bit DLL for use with a 64-bit JRE on Windows. (Theoretically, running such a
jar with a 32-bit JRE to access a 64-bit LO installation's URE jars could have
worked. But practically, those URE jars in turn require native DLLs, which
would then not have been available as 32-bit DLLs for use in the 32-bit JRE.)
For another, at least the unowinreg.dll resulting from --enable-build-unowinreg
on Fedora 33 would have had a dependency on libgcc_s_dw2-1.dll that would
generally not have been available in a target Windows environment.
There appears to be no pure Java way to read the Windows registry, but instead
of using a native code DLL for that, it appears to work just as well to call out
to reg.exe and parse its output.
This removes the --enable-build-unowinreg and --with-mingw-cross-compiler
configuration options. (The sole use of the MinGW toolchain in LO was for
building unowinreg.dll.)
Change-Id: I3283ea38c884d3221a205e5ab6ec99a2691ef474
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107140
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
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>
|
|
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>
|
|
The -fmodules-codegen flag has been in Clang for quite a while, but it
officially works with PCHs only with Clang11+, and even there's
it's better to use the properly named -fpch-codegen. This also
fixes a problem with Clang9 having only -fmodules-codegen but
not the -fno-* variant, causing the build to break.
Change-Id: I9a8c979426f95e8c1f77cbeab1df64390d7243b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103677
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: If8e965fa955aecdb9e7011bdddc690de9cad0c4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103120
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Skia is explicitly made to build optimized even in debug builds,
unless --enable-skia=debug is given, so $(PCH_MODULES_CODEGEN)
gets set even for it by com_GCC_class.mk , although normally
it's disabled for optimized builds as not worth it. Explicitly
disable the flag for Skia.
Change-Id: Icf030f0bdc99dbc476af585937c864f951d2b7ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102674
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Setting it in environment overrides this setting.
The rationale is to avoid introducing warnings like these appeared recently:
zipfile.py:1517: UserWarning: Duplicate name: 'cmd/ar/sc_bulletsandnumberingdialog.png'
(see e.g. https://ci.libreoffice.org/job/gerrit_windows/71910/consoleFull)
Change-Id: I8ae42e039ec3d028c01dbc4bcf422feae9e46271
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100268
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Miklos reported a Android configure error, which tried to run
autogen.sh for gb_Side=build, which is correctly forbidden. I
checked all the files timestamps for $(BUILDDIR)/config_host.mk
target - all ok, and somehow missed the JAVA_HOME test...
Since my commit 42aeb9f906ca4e23d118ff8563184f9315ef3b82
("cross-build: fix Java NI linking"), JAVA_HOME just makes
sense for the build side. So the tests just make sense for the
host side, if there was a --with-jdk-home supplied.
This results in a sensible, empty JAVA_HOME for the host side
and all Java builds I found already override JAVA_HOME with
JAVA_HOME_FOR_BUILD.
Change-Id: I1742a83466af70804f1700a1ca0cb6b6b77a7b12
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102676
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
LibreOffice has a JNI component on Windows and Linux, the
officebean. Therefore we need a host JDK for linkage to the
jawt, and a build JDK to compile the Java code.
Change-Id: I4138628ab3ea2ef5900a5b4e9281050ae84e4eb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102483
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Cross compiling these libraries requires to supply the cross-
compiler via the CC_FOR_BUILD environment variable. Since we have
to use the gcc-wrappers, we now need two different invocations
with different inclues and libraries, but just have fixed
environment variables. Also, the CC_FOR_BUILD clashes with LO's
own variant, but that is easy to fix.
So this change includes:
- gcc-wrappers: new option --wrapper-env-prefix to add a prefix
to the environment variable names
- gcc-wrappers: new option --wrapper-print-cmdline to dump the
real command called, when a verbose build is executed
- gcc-wrappers: default to exe, if the output has no extension
- unify build flags for gpg related libraries
Change-Id: I4e6a6ba3c6e09237c8ffefa40ce61131290a3852
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102482
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
(To minimize disruption with other people's potential use of the variable, when
it is not set during configuration make sure not to export it as empty from
config_host.mk, so that it can then still be passed as an environment variable
to individual `make` invocations.)
Change-Id: I785910f1076c05905e354ef846d16ffb7ea0a081
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101002
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>
|
|
Noop. Use --with-extra-buildid
Change-Id: I110514f6f58c1cd2ca635234a20cf560e6e3d6e6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98923
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
|
|
The optimization to instantiate templates already while creating
the PCH instead for every single compilation has been finally
accepted upstream, but it's opt-in.
Change-Id: Ia6456df05512329fc594f9ed0e400250c4f5029e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98948
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
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>
|
|
It was fairly pointless to be able to --disable-libnumbertext.
Besides, disabling it broke the ordinal page (etc) numbering feature:
"1st", "2nd", "3rd", etc showed up as "Ordinal-number 1",
"Ordinal-number 2", "Ordinal-number 3" etc.
Change-Id: I645169054a8fdc8dac89cd48b6c369fd61749467
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/96119
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
The option, available since Clang10, emits debuginfo for classes
with explicit ctors only together with the ctor, which avoids
redundant debuginfo for such classes, noticeably saving both build
time and disk space. https://reviews.llvm.org/D72427
I've been using this for quite some time, without problems.
Change-Id: I24e5339f983cb8d8990185436dd63e00f0d3ce60
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94756
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Bundled box2d with the build system of LO as a static library.
If --with-system-box2d was specified checks for instance box2d in
the system, defines SYSTEM_BOX2D and uses the library from the system.
Change-Id: Ifb05912f2acaff273b25abebafc5af1cac3afec4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94103
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
In raster mode the performance may make quite a difference, this is
the drawing library (that's now the Windows default) and LO developers
mostly do not need to debug Skia itself.
Change-Id: I42f0407d37a2294b062a41d94566e8a4f5f4354b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/93557
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I50ed05116df3f295af6406f0ee45610d9e1e031e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92619
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Clang-cl interprets MSVC's -arch option a bit differently (for MSVC
-arch:SSE2 seems to mean SSE2+, but SSE2-only for Clang). So use
Clang's -mxxx options when using clang-cl as CC/CXX. Also check
intrinsics once again if using CLANG_CC/CXX to compile Skia.
Change-Id: I64cd368ef4e5f4fcf1dbe877a1129f418d273a47
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92618
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
I.e. try to find and use Clang even if the default compiler is
something else. Skia is optimized to be built with Clang(-cl)
and in CPU-based raster mode some operations are several times
slower if built with something else (e.g. fmax/fmin do not get
optimized to inline assembly).
It is enough to select Clang to be installed in the MSVS installer.
At this point it unclear how to handle release binaries, if it
should work this way and enforced, or maybe Clang could be used
for building everything, or maybe some other way.
Change-Id: I6b95a0f2d5cbf176942d9e01136990b14be6dba8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92415
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...ever since it was introduced in 334a9f16cd1d1f9694f885c759903a41aa3d4833
"tdf#113211: fix calculations with big integers". (Only the AC_DEFINE'd #define
in config_host/config_global.h.in is used in sal/rtl/math.cxx.)
Change-Id: I4b84534b022b96fee725988906c047736e7a579b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92411
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
https://lists.freedesktop.org/archives/libreoffice/2020-March/084769.html
etc.
This reverts commit c76fdcf1cfa1242e66b50ebe80d6eac1baae37a9.
This reverts commit 10f52ab4d27263439d59f55f40e88ad2fde0cf71.
This reverts commit eac806e8dcd9ee6439ac8695978ff6b62cc6b8d2.
This reverts commit d591a682e46ff352f06a61c024ef661dd17f4ea4.
This reverts commit 12235d3390a7fc5146bf65f9d6166034b8a048ee.
This reverts commit 23245f723fb29262b8543d6447d1b0bb69cb50fb.
This reverts commit 91658b402b66b67c785687d5b3a76e3183fe76bf.
This reverts commit 5feadfad0cc3be2680213d2e5f6f786b2f4cc74f.
This reverts commit fecca49c309fc723c524f12fa671114b316a5562.
This reverts commit c6a9454e744289cf2004b42b3c90854b2db8382b.
This reverts commit a1a62a70411cb6041b5930ead08280d5e1e7b5f9.
This reverts commit 8512f4ca090c85477a6670438aeefe7fdfcf8a98.
This reverts commit 532ffb7a297d55b495141ce33692df5d9917b54f.
Change-Id: Iaa48d692bea2ca2468cdd5f8ad26ad91c0c31dde
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91199
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
I based the check on the gmake check, but that one doesn't need
the export, as gmake is what needs to be called for the build
to start. But ninja is currently only used during building NSS.
Also do not use Windows path for ninja on Windows, as NSS
actually invokes it from a shell script.
Change-Id: I0d8a86ee3688f27a376d547cd946bb4c59a547a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90922
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
<https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/54883/> had been a
case I noticed of a "Gerrit Linux clang/dbgutil" build failing due to stale PCH
information:
[...]
> [build GEN] compilerplugins/clang/sharedvisitor/makeshared.plugininfo
> fatal error: file '/usr/include/asm-generic/errno.h' has been modified since the precompiled header '/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/compilerplugins/clang/sharedvisitor/clang.pch' was built
> note: please rebuild precompiled header '/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_clang_dbgutil_64/compilerplugins/clang/sharedvisitor/clang.pch'
[...]
and this issue had apparently caused all those Gerrit Jenkins builds to fail for
at least a day. For unmaintained builds like those, I think it is better to
have a more robust setup, where stale PCH information cannot break the build.
Also, as those builds do not make compilerplugins.clean and rather share it
across builds, there should not be much of a performance impact when disabling
PCH in the analyzer.
(It turns out that compilerplugins/clang/sharedvisitor/analyzer.cxx would always
have enabled PCH, as compilerplugins/Makefile-clang.mk always passes in some
definition of LO_CLANG_USE_ANALYZER_PCH. Fixed that now.)
Change-Id: I7b8b24c1049c501634bd59c5fb482bec72427cf6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/90211
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
|
|
...after 358146bbbd1b9775c12770fb5e497b6ec5adfc51 "Bump macOS build baseline to
Xcode 11.3 and macOS 10.14.4".
This effectively reverts b7fd89100d8653dc73955780358fe31d38b68ebf "tdf#122218:
Baseline Xcode 9.3 ld presumably doesn't support -platform_version".
Change-Id: Ib79563babe3cc948556d5369b0f6b6a8d208cab2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89160
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
This will use -Og with GCC/Clang instead of -O0, which should make
unittests run faster without (hopefully) breaking anything related
to debugging. This is primarily meant to Jenkins builds, where
debug info is rarely needed (backtraces for unittest crashes AFAICT).
This can be also used to make LO itself run faster when developing,
but I personally do not find it worth it (with Clang and full PCH
this makes starmath build take about 70% longer, although presumably
for non-PCH builds the relative increase will be smaller).
Change-Id: I198d0759ebca94c90be662e02e0f1281a24d1d70
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88917
Reviewed-by: Michael Stahl <michael.stahl@cib.de>
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Tested-by: Jenkins
|
|
Change-Id: I3a725e4681c11f503dae57436b05b5a80ff2979c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88764
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...with --enable-werror (seen it fail with a local build against a locally
built Clang 5.0.2).
(bin/gen-boost-headers faces a similar dilemma with Clang needing to silence
-Wunknown-warning-option and GCC failing upon the silencing incantation. There,
we were able to hack around that with a preceding
#pragma GCC diagnostic ignored "-Wpragmas"
Here, the easiest approach appears to be a new COMPILER_PLUGINS_COM_IS_CLANG
analoguous to the existing COM_IS_CLANG.)
Change-Id: I9036261fdd238c8a020a1d88b4e75fd444f9e030
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88725
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...according to <https://github.com/llvm/llvm-project/commit/
25ce33a6e4f3b13732c0f851e68390dc2acb9123> "[driver][darwin] Pass
-platform_version flag to the linker instead of the -<platform>_version_min
flag": "In Xcode 11, ld added a new flag called -platform_version [...] This
patch adopts the new -platform_version flag in Clang, and starts using it by
default, unless a linker version < 520 is passed to the driver."
So detect new HAVE_MACOS_LD_PLATFORMVERSION and adapt
645fe53be0dc36535dba0ed684e21ca4cda80d70 "tdf#122218: Hack to avoid blurry text
with macOS SDK 10.15" accordingly.
(This also changes the passed -platform_verion sdk value from 0.0 to 0.0.0, for
cosmetic consistency with the default Clang behavior cited above. Also, after
f67e5ef9a5c71f3b35b1c67eb72794e44cc15410 "Drop broken filter-out of
-bind_at_load for Executable_soffice_bin on macOS" got included in the meantime,
the surrounding ifeq in desktop/Executable_soffice_bin.mk can be combined now.)
Change-Id: Ie1ddf2d618e2f1232c6b4e17ce17665851f3bd38
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88717
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ic69d0030a46fe4753cc75da58bb2c15cf009b135
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87023
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
These (starting with my patches for Clang-to-be-10) allowing emitting
debuginfo and functions into a dedicated object file, so that all
the normal compilations using the PCH can skip those, thus saving
the time. The debuginfo option seems to always be worth it. The codegen
option is more tricky, it doesn't seem to be worth it for optimized
builds (optimizing all the functions in that one object file costs
too much).
This requires also using --Wl,--gc-sections . The reason is that
the object file contains all template instances instantiated from the PCH,
so that they can be shared, but the template instance may come
from another library or use a private symbol from that library.
For example the std::unique_ptr<ScInterpreterContext>
in ScInterpreterContextPool in the header refers to ScInterpreterContext
dtor. But even though both these classes are private, the header
gets used also by scfilt, because there it is included by document.hxx
because of a private ScDocument data member. So even though nothing
in scfilt uses ScInterpreterContext, the PCH object file will refer to it.
Fortunately that template instance itself is not used by scfilt,
so --gc-sections will remove it.
Change-Id: I2a06ebcc4dd4175424b3a72ab3ebcaf2ac3ee295
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87011
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This marks the PCH as having an accompanying object file, and
this object file needs to be also built, but this allows the compiler
to skip generating stuff that'd be shared by all the objects using
the PCH. Currently it doesn't make much of a difference, few symbols
if any, but template instantiations could be shared this way, as
soon as Clang gets the necessary support (my WIP patch).
Change-Id: Ib1b86338d85a47b48979558435253dc2672a0da8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87009
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
We already get -Wdeprecated-copy (warning about implicitly defined copy
functions that will in the future be deleted because other user-provided copy
functions exist) automatically through -Wextra, where available.
-Wdeprecated-copy-dtor (warning about implicitly defined copy functions that
will in the future be deleted because of a user-provided dtor) is split off
into its own warning excluded from -Wextra for somewhat unclear reasons, see the
discussion at <https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=88136>
"-Wdeprecated-copy is draconian and shouldn't be in -Wall".
But -Wdeprecated-copy-dtor has been useful in finding issues (esp. the Clang 10
trunk version, which, unlike the GCC 9 version, also finds copy functions that
are implicitly defined because they are used from template instantiations), see
3e59716375a240576fd6d8759b32b4319506ed70 "Prevent
BroadcastRecalcOnRefMoveHandler copies" and
4f98cd0f9ce9c2a331a5d34b3ef9d18f9bb6b235 "ScShapeChild has broken copy
functions".
We need to disable -Wdeprecated-copy-dtor in files included from external/boost,
and in two compilerplugin/clang/test/ files.
Change-Id: I74b159c3a046e23661473ddbfe53c92c4136a9db
Reviewed-on: https://gerrit.libreoffice.org/85073
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...and require new-enough Bison for --enable-compiler-plugins to not generate
bogus loplugin:external warnings in Bison boilerplate code. (As happend for me
on macOS where /usr/bin/bison is version 2.3. Not sure which versions exactly
are too old, but at least 3.4.1 is known good. If other versions newer than 2.3
turn out to be problematic too, the configure.ac check will need to be adapted.)
No idea why there need to be three places across solenv/gbuild/ that set
gb_YACC (to the same bison in each case), but leave that to be cleaned up later.
Change-Id: I01d8219726f8df7895631b817866207327367759
Reviewed-on: https://gerrit.libreoffice.org/84650
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
The common usage pattern should be having one source file per each
instruction set and then one source file compiled with neutral flags
that dispatches to the relevant code based on runtime checks.
Which means that there can't be any one "correct" flag, otherwise
all files would get compiled e.g. with SSE4.2 but then CPUs capable
only of SSE2 would crash running that code.
Change-Id: I362bf66f672dae4588a48effe3bcd30c34ea75b3
Reviewed-on: https://gerrit.libreoffice.org/84227
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This indicates that the build targets the Online-based Android app, for
which we need to avoid various tweaks that are needed for the 'old'
Android app present in the android/ subdir of core.git.
In particular, the switch used in this patch fixes a RGBA vs. BGRA
confusion that caused yellow <-> cyan switch in the Online-based Android
app.
Change-Id: I5f394868f51ce87013677834cfafb967b9bb333e
Reviewed-on: https://gerrit.libreoffice.org/83342
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
(cherry picked from commit 49002a143a4534df5f6139e07fefd06174621c59)
Reviewed-on: https://gerrit.libreoffice.org/83718
Tested-by: Jenkins
|
|
Not quite complete yet, missing e.g. Vulkan sources, and the setup
is not completely correct either.
Change-Id: I2283bf12f0d226ff8a34554deae5a7bd69045971
|
|
At least when doing an aarch64 Flatpak build against org.freedesktop.Sdk//19.08,
which uses GCC 9.2.0 and passes in `CXXFLAGS=-O2 -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables
-fstack-clash-protection`, callVirtualMethod (in
bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx) would
decrement the stack pointer another 16 bytes after the
stackargs = alloca(...);
and before the asm block, so in the called virtual function, arguments read from
the stack would read garbage (and CustomTarget_testtools/uno_test would fail
with SIGSEGV at
> #0 0x0000ffffb733eb48 in rtl::OUString::operator= (this=0xaaaaf9c1ac30, str=...) at /run/build/libreoffice/include/rtl/ustring.hxx:453
> #1 0x0000ffffb733a7bc in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:99
> #2 0x0000ffffb733a87c in bridge_object::assign (rData=..., bBool=true, cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:115
> #3 0x0000ffffb733ade4 in bridge_object::Test_Impl::setValues (this=0xaaaaf9c1abb0, bBool=1 '\001', cChar=64 u'@', nByte=17 '\021', nShort=4660, nUShort=65244, nLong=305419896, nULong=4275878552, nHyper=0, nUHyper=187651311381888, fFloat=17.0814991, fDouble=3.1415926358999999, eEnum=-1698898192, rStr=..., xTest=..., rAny=..., rSequence=..., rStruct=...) at /run/build/libreoffice/testtools/source/bridgetest/cppobj.cxx:548
> #4 0x0000ffffb740bff4 in callVirtualFunction (function=281473755360772, gpr=0xffffd1ab1f28, fpr=0xffffd1ab1f68, stack=0xffffd1ab1d40, sp=8, ret=0xffffd1ab22c0) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/callvirtualfunction.cxx:63
> #5 0x0000ffffb740ca70 in (anonymous namespace)::call (proxy=0xaaaaf9c291c0, slot=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, returnValue=0xffffd1ab22c0, arguments=0xffffd1ab2230, exception=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:178
> #6 0x0000ffffb740d4c4 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch (pUnoI=0xaaaaf9c291c0, pMemberDescr=0xaaaaf9c55950, pReturn=0xffffd1ab22c0, pArgs=0xffffd1ab2230, ppException=0xffffd1ab2370) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/uno2cpp.cxx:361
> #7 0x0000ffffb740720c in (anonymous namespace)::call (proxy=0xaaaaf9c549c0, description=..., returnType=0xaaaaf9c00770, count=17, parameters=0xaaaaf9c3a210, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:120
> #8 0x0000ffffb74079a0 in (anonymous namespace)::vtableCall (functionIndex=40, vtableOffset=0, gpr=0xffffd1ab2510, fpr=0xffffd1ab2550, stack=0xffffd1ab2590, indirectRet=0xffffb7d24790) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:291
> #9 0x0000ffffb7407b00 in (anonymous namespace)::vtableSlotCall (gpr0=187651311618536, gpr1=1, gpr2=64, gpr3=17, gpr4=4660, gpr5=65244, gpr6=305419896, gpr7=4275878552, fpr0=5.4321266044931319e-315, fpr1=3.1415926358999999, fpr2=0, fpr3=4.0039072046065485, fpr4=0, fpr5=4.003911019303815, fpr6=8.9589789687541617e+102, fpr7=-4.4588500238274385e-308) at /run/build/libreoffice/bridges/source/cpp_uno/gcc3_linux_aarch64/cpp2uno.cxx:348
> #10 0x0000ffffb739e60c in bridge_test::performTest (xContext=..., xLBT=..., noCurrentContext=false) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:378
> #11 0x0000ffffb73a3d58 in bridge_test::TestBridgeImpl::run (this=0xaaaaf9c18550, rArgs=...) at /run/build/libreoffice/testtools/source/bridgetest/bridgetest.cxx:1162
> #12 0x0000aaaad292a3ec in sal_main () at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:509
> #13 0x0000aaaad29297a0 in main (argc=8, argv=0xffffd1ab31b8) at /run/build/libreoffice/cpputools/source/unoexe/unoexe.cxx:349
.)
By experiment, I found the problematic thing to be -fstack-clash-protection,
which can apparently be cancelled with a subsequent -fno-stack-clash-protection
at least on that GCC 9.2.0. (And -f[no-]stack-clash-protection appears to only
be available since GCC 8, and not at all for Clang, so check for it with
HAVE_GCC_STACK_CLASH_PROTECTION.)
Change-Id: If667fdf704b1ba20a04593b38d2d1f079280df41
Reviewed-on: https://gerrit.libreoffice.org/80701
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...on our baselines, since <https://gcc.gnu.org/git/
?p=gcc.git;a=commitdiff;h=b156ec373ccf27f4fcce7972de5e043d35acea43> (GCC 4.9?)
and <https://github.com/llvm/llvm-project/commit/
e0fc1a80cba8b91e3943f3287e7dcf68c6bb9b7f> "[stackprotector] Add command line
option -fstack-protector-strong" (Clang 3.5?)
Change-Id: I48237b2304a1ee273cc66f0bb458e890a5a2f21a
Reviewed-on: https://gerrit.libreoffice.org/80700
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Instead of having a lot of it hardcoded, which brings problems like:
- Clang-to-be-10 has switched to -std=c++14, so our hardcoded c++11
makes the build fail
- I cannot compile with my openSUSE-shipped clang, because it ships
only libclang-cpp and not the other libClangSomething libs
The possibility to explicitly set the necessary variables is still there.
Change-Id: I58d401d4584fa064f1c1351a8a06ff4e29643063
Reviewed-on: https://gerrit.libreoffice.org/80300
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
- in soffice.ini (sofficerc) the entry "CrashDumpEnable" default is "true"
- when false then the Dump.ini and the dump-file are not written
- when the switch --disable-crashdump is set, then the
switch "CrashDumpEnable" set to "false"
- when the entry "CrashDumpEnable" is missing, in this case is the
default true, too
- the checkbox under Options-General "Send crash reports to ..."
is deactive and shows off (only view, not change the config)
- when set the environment variable "CRASH_DUMP_ENABLE" to any char
then the switch "CrashDumpEnable=false" are overrules with true
and the Dump.ini and dump-file are write
Change-Id: I34e7795640eb95d111e18b0ad46ec67b2c126b19
Reviewed-on: https://gerrit.libreoffice.org/79273
Tested-by: Jenkins
Reviewed-by: Juergen Funk (CIB) <juergen.funk_ml@cib.de>
|
|
This is the core/ part of the patch.
Add xapian-omega search to online Help.
The patch replaces Google custom search with xapian-omega search.
A new build key is introduced.
--with-omindex=server : Localizes and adds the xapian result page,
adds the xapian form to each Help page.
--with-omindex=noxap : do not localize the result template and do
not add a form in the Help page.
--with-omindex will force Online Help build.
Default is noxap
NOTES:
- searches returns resuls only on localized Help pages, avoiding same
resulis in many languages.
-xapian-omega databases must be built in server
TODO:
- Tweak the xapian-omega result page CSS and markup.
Change-Id: I5e3fe4191a3b054e3b6403f7cb5640953d92ba42
Reviewed-on: https://gerrit.libreoffice.org/79368
Tested-by: Jenkins
Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org>
|