Age | Commit message (Collapse) | Author |
|
…by a simple/static $(gb_UnpackedTarball_workdir)/foo
see also 0c4c84a14b01c71c76a9c45a7f26aec4d64f3e4f
Change-Id: I8e6aa55c85534c4446556548910c950ddbe7c6fc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167163
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
|
|
A number of them didn't use it at all, others had it hand-written
in various ways.
Change-Id: Iaf86325f9cdc032926bac917dc3eef4e34661544
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132818
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
No idea why we just provided the platform flags when cross-
compiling. In the curious case, where the host platform is
detected as x86_64-pc-mingw32 per default and we actually
want to override it with x86_64-pc-cygwin, we don't do a
cross compile, but must override the host platform.
But there is additional special handling needed for the omitted
cross-platform build in the special case of --host=i686-pc-cygwin
and --build=x86_64-pc-cygwin, where we deliberatly ignore cross
building; Windows is already a slow build, so try to keep this
optimization (AMD64 can execute x86 binaries).
There is the theoretical case, where the externals config.guess
would have detected something else and that "magically" even
worked, while the LO detected triplet would fail, but this
should be fixed in the external in any way.
Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
Change-Id: I76f8cab70d4c1a5b98bb5ba1608676d34570694b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119879
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
...as seen when running under UBSan `instdir/program/soffice --headless
--convert-to epub` of caolan/libmspub_icu_global_buffer_overflow.sample from the
crash-testing corpus.
<https://www.w3.org/TR/SVG11/implnote.html#ArcImplementationNotes> specifies:
"If the endpoints (x1, y1) and (x2, y2) are identical, then this is equivalent
to omitting the elliptical arc segment entirely." (And getEllipticalArgBox's
xmin, ymin, xmax, and ymax out parameters are pre-filled with suitable values at
the call site in getPathBBox, so that we can return here without setting those
out parameters.)
Change-Id: I6b0b693354648f4015cec2395737fb9abe5ae956
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119680
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
- configure with:
- --host=wasm64-local-emscripten
- had to make a few externals optional, so adding:
- --disable-nss
- --disable-cmis
- --disable-curl
Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Some versions of the patch program are picky about that.
Change-Id: I0006ecefcf4afe10971c5f3571c3d32d97598696
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109998
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
Change-Id: Ibc59469b74d54a2b307ea708ea5c4a752532f0b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109840
Tested-by: Jenkins
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
See instructions in solenv/gbuild/Trace.mk . This generates a file than
can be viewed e.g. in the Chromium tracing view.
Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...for ASan/UBSan builds using Clang older than current trunk twoards Clang 9,
as announced at
<https://lists.freedesktop.org/archives/libreoffice/2019-May/082654.html> "Re:
[Libreoffice-commits] core.git: The -fvisibility-ms-compat hack is no longer
needed for UBSan on Linux...". (And drop the no longer needed
solenv/sanitizers/asan-suppressions, which people might still reference from
their ASAN_OPTIONS.)
Change-Id: Iedc0c5955366d2cbe7dc847990e2b1576750e85b
Reviewed-on: https://gerrit.libreoffice.org/72493
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As in, really disable, so that they do not even show. This moreover
avoids tons of D9025 warnings from MSVC about overriding -W4 with -w.
Change-Id: Ia2e72fd72d883d91bdd89e467ee42f259e2ae033
Reviewed-on: https://gerrit.libreoffice.org/72899
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
|
|
...which fixes an issue encountered when compiling with Clang against trunk
libstdc++ (which contains pre-C++17-only code that triggers
<https://bugs.llvm.org/show_bug.cgi?id=41896> "Bogus 'error: no return statement
in constexpr function' when void return type is 'templated'")
Change-Id: I33368996c8ac8cf32893ba1b631ace2a606dafb1
Reviewed-on: https://gerrit.libreoffice.org/72409
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I9d0a7e782b1bd5955cb524153b8a7bdea9e174e7
|
|
...with latest Clang trunk towards Clang 9. All the no-longer necessary hacks
are made conditional on new NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY, which is
still set for UBSan builds with older Clang on Linux (but which should
eventually be purged).
Various classes needed additional SAL_DLLPUBLIC_RTTI annotations, as building
with UBSan instrumentation can generate references to RTTI symbols from
additional places like outside a dynamic library that used to hide those symbols
by default (but used to not hide them for old UBSan builds thanks to the
-fvisibility-ms-compat hack).
The odr-violation suppressions in solenv/sanitizers/asan-suppressions (which is
not referenced from anywhere in the code base, but meant to be included in an
ASan/UBSan build's ASAN_OPTIONS env var) are also no longer needed when
NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY is false.
Change-Id: I24ec3e388b0cbab50dbe2bf008d9569bff7bf25a
Reviewed-on: https://gerrit.libreoffice.org/70829
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I23aa89602206bedf3b1faf58c5e153a4d06cb515
Reviewed-on: https://gerrit.libreoffice.org/43997
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I43805ac8c3d5c1b65519da02c3cc50fdb9729ea6
Reviewed-on: https://gerrit.libreoffice.org/42941
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Support for arm64
Change-Id: I9f5f6220dd4f3e6e2c008f9f8beebbaeb75a1f6b
|
|
Change-Id: Ibb87f4a14fda6957149ca52083387760ff6e60a3
|
|
Change-Id: I6cb707663e2abad8761b172773ee70f9caf4a87d
Reviewed-on: https://gerrit.libreoffice.org/22835
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
Change-Id: Ic77d0510801f3655d914aea0e8ce66476853358a
|
|
...in anticipation of building with clang-cl.exe on Windows
Change-Id: I1d723c9d3b5ca8a2bc6b27ef0189a7b053581398
Reviewed-on: https://gerrit.libreoffice.org/19928
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: If8d6c8da1be1e540d641f20ac90e7877feae27be
|
|
Change-Id: If13cdf90de752626bbd37877fea045faae0616cb
|
|
configure.ac was setting VERBOSE=YES/NO when really
we use verbose=t or verbose=
Change-Id: I47aee8d177cb2d788a62ecdbbb9cc3695c2bb299
Reviewed-on: https://gerrit.libreoffice.org/17634
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
Change-Id: I09f0528420577e4b417ee4e39a52150777910d13
Reviewed-on: https://gerrit.libreoffice.org/17569
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
|
|
...as discussed in 371cc81bd9ccbfbed25f810e70899c044280349e "external/liborcus:
Fix Linux RPATH:"
* When an external module produces multiple libraries (that we all install) that
depend on each other, they need to contain $ORIGIN in RPATH (strictly
speaking, those that do not depend on any other libraries from the module
would not need that, but it is harmless and easier to do that way).
* When an external module's libraries depend on other external modules'
libraries, and (at least some of) those other external modules are not
configuread as --with-system-*, they need to contain $ORIGIN in RPATH (again,
for simplicity, some libraries may get that even if they would not strictly
need it).
* Try to outsmart the external modules' libtool instances to not add (ultimately
bogus) paths to RPATH for dependencies on libraries from external modules
(either from the same module, or from anohter module not configured as
--with-system-*). The only time we do not outsmart libtool, and instead rely
on it (hopefully?) doing the right thing is when a given external modules'
libraries depend on libraries from excatly one other external module, and the
latter is configured as --with-system-*.
* That outsmarting means that if an external library depends both on external
libraries provided by modules not configured as --with-system-* (so RPATH
contains $ORIGIN, and the outsmarting is not suppressed) and on external
libraries provided by modules configured as --with-system-*: Then if the
latter are in unusual locations on the system that would require an RPATH
entry (which might be provided via the corresponding "pkg-config --libs", say,
and presumably would be honoured by libtool if we did not outsmart it), then
those paths are now erroneously missing from RPATH.
* That outsmarting also causes linking of some utility applications in module
redland to fail, but those are ultimately unused, so cut them off by patching
their respective sub-directory Makefile.in.
Change-Id: Iec05b3568fbcf04987018322c328b769ae4f5dab
|
|
Change-Id: Iec611290770ae0393eb787a3883bb22a12340b0a
|
|
Change-Id: I97dbebbe7ecbfdc2d4ad37ac53d22026d5e67738
|
|
As discussed in b4f6b26b5a1a78fecfa95ec2eb7ac8b80495d8aa "SAL_DLLPUBLIC_RTTI for
proper RTTI visibility for LLVM," RTTI-based -fsanitize= checks with Clang on
Linux need special precautions to make RTTI symbols visible across DSOs. The
approach taken there, as well as in 598d8194b0ea1a64e0ebba28a86c128bafa57c7c
"Visible function type RTTI for Clang -fsanitize=function," was to add explicit
SAL_DLLPUBLIC_RTTI annontations to relevant type definitions. However, for
-fsanitize=vptr that would have required many more of those, so it appears
easier to "misuse" -fsanitize-ms-compat in that case, which happens to give all
RTTI symbols default visibility (while otherwise still honoring our
SAL_DLLPUBLIC/PRIVATE annotations).
The SAL_DLLPUBLIC_RTTI annotations from 598d8194b0ea1a64e0ebba28a86c128bafa57c7c
"Visible function type RTTI for Clang -fsanitize=function" can likely be removed
again.
Change-Id: Ibeff7ab8c908111a7dc66ff0677204f112b24db8
|
|
...not only when building the libs themselves, but also when including their
header files from other code. (Omission only becomes obvious with hidden
function type RTTI causing false positives from Clang -fsanitize=function.) As
these external libs do not record the decision to enable visiblity in a config
header file that gets included, it appears easiest to hack that knowledge into
gbuild for now. (Note that libodfgen internally uses librevenge.)
Change-Id: I6a3a722d561b8cbce6e5b1f27d7aa2d7602f3cdf
|
|
Change-Id: I32c115aa46855375cc28402f21f4f63299e165d4
|
|
Change-Id: I1df6ad9a53001348f269d4156dd09c4d2c361c26
|
|
Change-Id: Ic23c434770159ddea1f05ac0ef49572b387ebb54
|
|
Change-Id: Ic05027fafc9bed8d37306be9c7da63e53d1c6196
|
|
Change-Id: I8499c79358c598f71585234d7007e981ff4d88e1
|
|
Change-Id: Ia28bac4b12f23f3e85e42e323b35d8715a6d5d02
|
|
Change-Id: I04a446e6b8a8352be9f091980bca31842bb7e643
|
|
Change-Id: I9a4719e60f910256c529551fdbb387e98aefd6ce
|
|
Change-Id: I8f2176500bf620cd5e4cdf434e6122b6163b3e0f
|
|
Change-Id: I9f60fd317f3a2995a182d51d06059bd994cf837c
|
|
...from (potentially negative) double to unsigned
Change-Id: I2f922beec7201a8d769133e879208d2e951e6429
|
|
Change-Id: I3bb3c90142cbbd32877ba5e3d9070bc52ee76df9
|
|
Change-Id: Ibecd7a89491b487bec54e8a86edbb1b133cdb8f0
|
|
problem
...LibreOfficeDev.app/Contents/MacOS/librevenge-0.0.0.dylib: Too many levels of symbolic links
(librevenge-0.0.0.dylib --> librevenge-0.0.0.dylib: broken symbolic link to librevenge-0.0.0.dylib)
The reason for this is that symlink librevenge-0.0.dylib
(UnpackedTarball/librevenge/src/lib/.libs/librevenge-0.0.dylib -> librevenge-0.0.0.dylib)
is copied via cp --no-dereference, thus becoming linked to self.
Change-Id: I4b918c35c594800fb2d7f84ee0ee9f2ff2a5fe14
Reviewed-on: https://gerrit.libreoffice.org/9783
Tested-by: David Tardon <dtardon@redhat.com>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I46079625b9aa6fd4e1c205a381d2c157b51dc7e4
|
|
Change-Id: I9e1fc613816c943f4fb1033185e34e3acf317f1d
|
|
Change-Id: Idfd73565c29c4ebcf561955fa965a81888a59315
|
|
Change-Id: Ib3339689d41f02b258f6c398887faae28e602a5c
|
|
Change-Id: I6aeaa95079e37e710e5b8b1b8ce24464e11f45bb
|
|
Change-Id: I3a2c9f56e87ee6395bd3505a8fe372632e242312
|