Age | Commit message (Collapse) | Author |
|
...for those who pretend they know what they are doing (e.g., to experiment with
building against Java 12 which no longer supports Java 1.6 source/target, even
though that results in a build that is not baseline compatible).
Change-Id: I6e8617bc5b90212473652bdfac40bb48e9623a08
Reviewed-on: https://gerrit.libreoffice.org/71218
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I496204ead6c495c4fee2cee18a5b9d0fd22eb8c0
Reviewed-on: https://gerrit.libreoffice.org/70951
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
... since on some boxes vswhere returns no results when VS 2017 is present
Change-Id: Ieabfbbc30195008ef93147d7d390eee58fa2b7f9
Reviewed-on: https://gerrit.libreoffice.org/70861
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Tested-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: I0eb35ce0c19c0b235f61216c8d1894e668c8b33d
Reviewed-on: https://gerrit.libreoffice.org/70853
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I633047306372ce285bf3531c609f364addf927c8
Reviewed-on: https://gerrit.libreoffice.org/70854
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
Tested-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: I8e08efb549ebd52c37183a1185d6de73f2b00601
Reviewed-on: https://gerrit.libreoffice.org/64630
Reviewed-by: himajin100000 <himajin100000@gmail.com>
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
This got broken again due to confusion about the interaction between
the various debug/symbol/whatever variables, so let's try to clean it
up once more. So gb_SYMBOLS or any other global flag is no more.
For checking whether a build target should get symbols, use
gb_LinkTarget__symbols_enabled, which is internally controlled by
gb_ENABLE_SYMBOLS_FOR (and flags from configure, command line or
wherever affect that).
This commit breaks the debug/nodebug split for PCH files, but fixing
that is a relatively separate and complex change, so it'll be done
in another commit.
Change-Id: I6060dd38684445bb761e664344fb530386481332
Reviewed-on: https://gerrit.libreoffice.org/70369
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: I20ed4c7daa9cde48ba65f92e5b4cc7e00972fe81
Reviewed-on: https://gerrit.libreoffice.org/70477
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Call me pedantic.
Change-Id: I96b8b7ef511508da0df75589475eaf13d639a7c9
Reviewed-on: https://gerrit.libreoffice.org/70365
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This reverts commit 50580f452cc7c88a231831619a3f05958ce56460.
Revert "raise cairo baseline to 1.10.0"
This reverts commit 58a0e60dee0d27a699f856827c20b792417d3478.
32bit baseline is currently at cairo 1.8.8
Change-Id: I5156df6aee03dbbb2e209dbd5717a98580256170
Reviewed-on: https://gerrit.libreoffice.org/70260
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I1816f23fea88e6b840539a88504956b00a546522
Reviewed-on: https://gerrit.libreoffice.org/70243
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I721b80d7ce28d36babbd2bd1957fcbd6a2d27a27
Reviewed-on: https://gerrit.libreoffice.org/70242
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Fixes CVE-2019-9636 CVE-2019-5010 CVE-2018-14647
Change-Id: If0a115960aed1ee90b63e6716c844669f0ec91e5
Reviewed-on: https://gerrit.libreoffice.org/70182
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: Iab63cf16f8c12c8148a8ac7eaea68007d4c27f23
Reviewed-on: https://gerrit.libreoffice.org/69891
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: Ia20647012cee1d25823779b7384c5fd43b4e1712
Reviewed-on: https://gerrit.libreoffice.org/69923
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
|
|
Change-Id: I5d6cfd5b9b4049ee16ffa038bac2db20968b02b3
Reviewed-on: https://gerrit.libreoffice.org/69812
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
Change-Id: Ie3eae75f13d27f3fce11acb66073dd51c0d41a32
|
|
In my macOS build, that clang::tooling::runToolOnCodeWithArgs invocation failed
to find headers like cassert and assert.h, which works now with
COMPILER_PLUGINS_TOOLING_ARGS=-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -isystem /Users/stephan/Software/llvm/inst/include/c++/v1
added to my autogen.input (I build against my Clang trunk libc++ whose headers
are at /Users/stephan/Software/llvm/inst/include/c++/v1).
Change-Id: Idbffa39c9fd4a88743fd498b8f7b6c9c56d7630d
Reviewed-on: https://gerrit.libreoffice.org/69538
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Because it does both a compile and a preprocessor check.
Change-Id: I2f144ea63ae1481822bb239127f0f5a934e22e73
Reviewed-on: https://gerrit.libreoffice.org/68971
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Change-Id: Idbdd2a97cdcc7f874c12cff8e024214badda1522
Reviewed-on: https://gerrit.libreoffice.org/68973
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
Reviewed-on: https://gerrit.libreoffice.org/68861
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
(cherry picked from commit 172f58ca7cdf323971a9e450620c669fe159c327)
Change-Id: I26c54ad52ab53802dc368b0bfcbde84affa46fdd
Reviewed-on: https://gerrit.libreoffice.org/68897
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
This adds --enable-poppler configure option.
Poppler can be enabled/disabled by setting this
parameter to yes or no.
Change-Id: I42ba2d27de7b5014d28523394310616d20073b71
Reviewed-on: https://gerrit.libreoffice.org/68602
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/68842
Tested-by: Jenkins
|
|
pg_config is meant for linking server extensions,
clients should use pkg-config instead to build against libpq.
This fixes build with PostgreSQL 11.
Change-Id: Ic0b5fc9cb7169f44c00a1edf7218212c360ec235
Reviewed-on: https://gerrit.libreoffice.org/68734
Tested-by: Jenkins
Reviewed-by: Tomáš Chvátal <tchvatal@suse.cz>
|
|
Change-Id: I20acdccd1faa7b8edf7a5786be124ae063ebca67
Reviewed-on: https://gerrit.libreoffice.org/68405
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I083583b86fa404eb16eea354ef9e6d22cf4c62fe
|
|
Change-Id: Iee70a15bb21ae1840e07583c958c094d37431d02
Reviewed-on: https://gerrit.libreoffice.org/68298
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Iede1d3321e909329cb0754a26e5b4bee4bb60316
Reviewed-on: https://gerrit.libreoffice.org/67752
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
as our new baseline (as discussed in ESC call 2019-02-07)
Change-Id: I8a22fab6a1f9a713cb55b4c5d8173c3bbcd28587
Reviewed-on: https://gerrit.libreoffice.org/67387
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
LDAP support is mainly for ldapbe (LDAP configuration backend), the
libpq one is just a by-product... so "in Base" is wrong
Change-Id: I342e579b5a832f6a4722499da3f0f1c35f4c0a5d
|
|
Change-Id: Ifbd3903494a81e7b155bf6468f6ca2c50b3370a4
Reviewed-on: https://gerrit.libreoffice.org/65958
Tested-by: Jenkins
Reviewed-by: Markus Mohrhard <markus.mohrhard@googlemail.com>
|
|
Change-Id: Ie186b828d500b661029704f95f4c03e56d69c282
Reviewed-on: https://gerrit.libreoffice.org/67382
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
By default for clang this tries to use first lld and then gold,
for gcc it just tries gold.
https://lists.freedesktop.org/archives/libreoffice/2018-June/080437.html
https://lists.freedesktop.org/archives/libreoffice/2018-July/080484.html
Change-Id: I669a8fa7671553f0cf78ddf82c51364fcdb0891b
Reviewed-on: https://gerrit.libreoffice.org/65426
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Currently done only on Linux, as I'm unsure about the status on other platforms,
and it seems that on Darwin the test passes successfully but later there are
problems. Feel free to add your platform.
https://lists.freedesktop.org/archives/libreoffice/2018-June/080437.html
https://lists.freedesktop.org/archives/libreoffice/2018-July/080484.html
Change-Id: I232ead45a1aff15cc738c612750ac28aedc08e83
Reviewed-on: https://gerrit.libreoffice.org/65425
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
Currently only done on Linux, I'm not sure about the status on other platforms,
feel free to add your platform.
https://lists.freedesktop.org/archives/libreoffice/2018-June/080437.html
https://lists.freedesktop.org/archives/libreoffice/2018-July/080484.html
Change-Id: I5997f54e530c8078250eb7c116cb6bd2604e7925
Reviewed-on: https://gerrit.libreoffice.org/65424
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
This is necessary for building with clang-cl, where $CXX_X86_BINARY needs to
match $CXX (i.e., both invoke clang-cl) so that the compiler switches (which
have been determined based on the nature of $CXX, i.e., are Clang-specific when
$CXX is clang-cl) passed to $CXX_X86_BINARY are actually understood by it.
(Building extensions/source/scanner/twain32shim.cxx failed with "cl : Command
line error D8021 : invalid numeric argument '/Wendif-labels'".)
For now, my local clang-cl build will just pass a suitable CXX_X86_BINARY
similar to the passed CXX (but with --target=i686-pc-windows-msvc -arch:SSE
instead of --target=x86_64-pc-windows-msvc) into autogen.sh.
Change-Id: Id958525f97e1d16f17af49e0b0288c1018885749
Reviewed-on: https://gerrit.libreoffice.org/67228
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
commit c3ab3df902b9e2ad363d1eca14da8f9f7f1567bb
Date: Thu Oct 14 09:53:40 2010 +0200
changed the configure.ac to require "Patched by Libreoffice", which was
possibly an error
Change-Id: I6f8e302baeed054f36b54f8bfb6f5cad826ee788
Reviewed-on: https://gerrit.libreoffice.org/67199
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
...as demanded by the C++17 standard, and required in
sc/source/core/tool/math.cxx. At least when building an --arch=i386 Flatpak
(where CFLAGS/CXXFLAGS are passed in containing, among others, -O2), that failed
when using -std=gnu++2a (instead of -std=c++2a) due to what looks like an error
in glibc (cf. <https://flathub.org/builds/#/builders/22/builds/797>).
...and fix fallout in external/firebird for Linux x86 32-bit build: While GCC
defines both __i386 and __i386__ (both as 1) regardless of -std=gnu++* vs.
-std=c++*, it defines i386 (as 1) only for -std=gnu++*. But various places in
the external/firebird sources check for i386 (among them src/common/common.h,
which fails with
#error Define FB_CPU for your platform
if i386 is not defined).
Change-Id: I7dce1961c79aeaccc82b1e2bdc350e02730d46af
Reviewed-on: https://gerrit.libreoffice.org/67105
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
partially reverts 182f5a0f34fa45d2f74ba22eda41d4e39dca93e5 in the sense
that configure still insists on autoconf 2.68, but in a way that allows
to specify an already installed copy (that the libnumbertext build
already picked up successfully)
While there is autoconf268 package, it gets installed as autoconf268, but
aclocal doesn't provide a way to use something else than "autoconf"
In the spirit of "keeping it simple", no conditional check is done
whether libnumbertext is actually enabled or not.
Change-Id: Ice05a70ef56a4ed3428c74d15d6aeeaa54f71c0b
Reviewed-on: https://gerrit.libreoffice.org/67159
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Jenkins
|
|
When no CFLAGS are passed into autogen.sh,
f104b3cafee63b47a735cfdce0f05dab2eedbb91 "tdf#72987 run firebird test for little
endian only for now" (introducing AC_C_BIGENDIAN before AC_PROG_CC) caused
CFLAGS in config_host.mk to accidentally be set to -g -O2 (instead of being left
undefined).
Change-Id: I639ce74b468e7fb25a6bda97346c7f97d6b829aa
Reviewed-on: https://gerrit.libreoffice.org/67125
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
LO's own configure doesn't need it, but the
ExternalProject_libnumbertext requires this version; since it's
available in RHEL6 as "autoconf268", just keep it simple and require it
in the top-level configure.
Change-Id: I43a6ef10089363c344f06134d75f54685ed7026b
Reviewed-on: https://gerrit.libreoffice.org/67002
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
cf. <https://github.com/ivmai/libatomic_ops/> (as mentioned in
external/libatomic_ops/README)
Change-Id: Ibd50ca81695cbcd73e005b0bbbd46ceb62b1e9dc
Reviewed-on: https://gerrit.libreoffice.org/66912
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...which was at maximum set to GCC's -finline-limit=0 -fno-inline
(solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug
builds "since forever", but that looks very much like cargo cult: -fno-inline
"is the default when not optimizing" anyway
(<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it
is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline
(and maybe was present for ancient compilers that only supported -finline-limit
but not -fno-inline?).
Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874
Reviewed-on: https://gerrit.libreoffice.org/66836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...that is documented as: "Does nothing. Preserved for backward compatibility."
ever since <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=160384> from
2010.
-fno-default-inline was the only value ever set in gb_DEBUG_CXXFLAGS, so the
latter can be removed now.
The use of gb_DEBUG_CXXFLAGS had accidentally already been removed from
gb_LinkTarget__get_debugcxxflags with e751e24250fda31dde52b3c65ca79f86142dc789
"--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutil",
and that leaves gb_LinkTarget__get_debugcflags and
gb_LinkTarget__get_debugcxxflags with identical definitions, so replace those
two with a single gb_LinkTarget__get_debugflags.
Some external modules had used only gb_DEBUG_CXXFLAGS, when this was apparently
meant to be used in addition to gb_DEBUG_CFLAGS, so those uses have been changed
to gb_DEBUG_CFLAGS now.
Change-Id: I84ea0ab1233569b0b02ca057240a71f138352381
Reviewed-on: https://gerrit.libreoffice.org/66808
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as emitted by at least GCC 8.2 with --enable-optimized, e.g. at:
> In file included from include/rtl/ustring.hxx:37,
> from include/cppuhelper/factory.hxx:26,
> from unoxml/source/rdf/librdf_repository.hxx:24,
> from unoxml/source/rdf/librdf_repository.cxx:20:
> include/rtl/string.hxx: In static member function ‘static std::shared_ptr<{anonymous}::librdf_TypeConverter::Node> {anonymous}::librdf_TypeConverter::extractNode_NoLock(const com::sun::star::uno::Reference<com::sun::star::rdf::XNode>&)’:
> include/rtl/string.hxx:294:27: error: ‘*((void*)(& type)+8).rtl::OString::pData’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> rtl_string_release( pData );
> ~~~~~~~~~~~~~~~~~~^~~~~~~~~
> unoxml/source/rdf/librdf_repository.cxx:2094:30: note: ‘*((void*)(& type)+8).rtl::OString::pData’ was declared here
> boost::optional<OString> type;
> ^~~~
This appears to be a common pattern of false positives with uses of
boost::optional, common enough to disable the warning globally for affected
compilers, even if there would also be useful findings by that warning (e.g.,
<https://gerrit.libreoffice.org/#/c/66619/> "Fix -Werror=maybe-uninitialized").
I didn't bother to file a GCC bug for the reproducer used in configure.ac,
<https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=maybe-uninitialized>
already shows lots of open bugs in that area, and the documentation at
<https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Warning-Options.html> states that
"GCC may not be able to determine when the code is correct in spite of appearing
to have an error."
(Clang appears to not support -Wmaybe-uninitialized at all, so exclude it from
the configure.ac check, to not have the check's failure result in an unsupported
-Wno-maybe-uninitialized end up on the compiler command line.)
Change-Id: Ifb9ca4c342750eae54f7e1a01506101310484c7e
Reviewed-on: https://gerrit.libreoffice.org/66621
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I6cdfc50b2385c426e20ce0e9b216b18c763249b8
Reviewed-on: https://gerrit.libreoffice.org/66506
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Without that modification, it finds dconf in linux system and then compilation fails when it tries to build configmgr/source/dconf.cxx because dconf headers are not found in Android NDK.
Change-Id: I25ab7f1ce66ed491f08a526e462e00957135b0c2
Reviewed-on: https://gerrit.libreoffice.org/65987
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: Id416ff399e443175b7c7d608c8a7a4bc38eeedcf
Reviewed-on: https://gerrit.libreoffice.org/66145
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
|
|
Change-Id: Id068f1c1b70c3db3d3a0faa5ebe7706f205fe4da
Reviewed-on: https://gerrit.libreoffice.org/65932
Tested-by: Jenkins
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
|
|
Update url according to LODE current version (4.2.1) because
the previous one does not support mkdir -p, which is used
by libcdr and libqxp now.
Change-Id: I7e50e46d2101a3cbd757d683f2d3550f896fc750
Reviewed-on: https://gerrit.libreoffice.org/65882
Tested-by: Jenkins
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
|
|
Change-Id: I41aa2f27b3e9b60c0c2e26dc3490cbeeb6247ee9
Reviewed-on: https://gerrit.libreoffice.org/65698
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|