Most of ubsan.patch seems to have been applied upstream, and I can’t
reproduce the issue referenced for the remaining bits, anyway it is
better to push such changes upstream first.
Change-Id: Ie56786c01c06d3542052cd91e36d1f707092beba
Reviewed-on: https://gerrit.libreoffice.org/15643
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Upgrade to the latest patch from http://bugs.python.org/issue17797
which appears to work even if you invoke from cmd.exe
Change-Id: I85f1cc5ad7d8c059d972ae2a6fd2be1bb5604c2c
Seems that when cross-compiling to Android from Linux, we apparently
have used either the build platform's pkg-config files for ICU, or the
build platform's icu-config. Both of which are obviously the wrong
thing to do, but apparently it has worked by accident anyway.
This makes building for Android on OS X proceed past harfbuzz, at least.
Change-Id: I27351f6177438697a1cded642c8c669ba7221009
Besides, wtf is it using -fast by default so the binaries don't run on any
system other than the one that did the build?
Change-Id: I5adc26fb6370a5292721df3167afc5485c15cb0a
Clang trunk since r231211 with -pedantic-errors now emits
"Cbc_C_Interface.cpp:379:55: error: format specifies type 'void *' but the
argument has type 'char *' [-Werror,-Wformat-pedantic]"
Change-Id: I5d410068f1cd82334f26148df30a45dbc9eabd0a
... and remove the definitions in makefiles, except in fpicker, which
defines a different value for the Vista file picker.
The WINVER value is derived automatically from _WIN32_WINNT by SDK
header sdkddkver.h.
Change-Id: I73358a9bf5d070f71821654cae2a29335a754a21
Following up on 7a4cc19791 "Also on Linux do not
export symbols from static orcus libraries" that turned out to not be enough to
prevent ASan ODR violation reports after
f0aa1a78fb "For Clang -fsanitize=vptr use
-fvisibility-ms-compat, not -fvisibility=hidden." Given that liborcus is only
ever linked in as a static archive, it is hopefully OK (intended, even?) to not
export any of its symbols.
Change-Id: Ib8eb084def1725374747a389065bf8186218786e
...detecting an uninitialized encAlgorithm value is passed into parser->getObj
(where it is presumably ignored for that specific set of arguments) in
XRef::fetch.
Change-Id: I511c8222ca8483aea1f475ba2aaefbc0cfb7dd5b
As discussed in b4f6b26b5a "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 598d8194b0
"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 598d8194b0
"Visible function type RTTI for Clang -fsanitize=function" can likely be removed
again.
Change-Id: Ibeff7ab8c908111a7dc66ff0677204f112b24db8
autoconf < 2.61a uses "echo" here and for some bizarre reason that
converts " inside ' to \ so remove the " to get it to work.
echo 'foo="bar"'
foo=\bar"
Change-Id: I6bee94d4d075ce953f5788b7fdf9d3b66a7db0c7
This fix supports building jpeg-turbo on both cygwin 32 nd 64 bit.
When only cygwin 64 bit is used, then it can be simplified by
passing BUILD_PLATFORM to configure script on all platforms.
Change-Id: Id335282f1761fcf7313fb18a6b9250e5eac392e4
Reviewed-on: https://gerrit.libreoffice.org/14315
Tested-by: Michael Stahl <mstahl@redhat.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
...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