At least on macOS x86-64 you get a warning
> [build LNK] Library/libwpftdrawlo.dylib
> ld: warning: direct access in function 'std::__1::__shared_ptr_pointer<librevenge::RVNGInputStream*, std::__1::shared_ptr<librevenge::RVNGInputStream>::__shared_ptr_default_delete<librevenge::RVNGInputStream, librevenge::RVNGInputStream>, std::__1::allocator<librevenge::RVNGInputStream> >::__get_deleter(std::type_info const&) const' from file 'workdir/UnpackedTarball/libzmf/src/lib/.libs/libzmf-0.0.a(ZMFDocument.o)' to global weak symbol 'typeinfo for std::__1::shared_ptr<librevenge::RVNGInputStream>::__shared_ptr_default_delete<librevenge::RVNGInputStream, librevenge::RVNGInputStream>' from file 'workdir/UnpackedTarball/libcdr/src/lib/.libs/libcdr-0.1.a(CDRDocument.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
The reason is that libzmf uses -fvisibility=hidden and generates
> $ nm -m workdir/UnpackedTarball/libzmf/src/lib/.libs/libzmf-0.0.a | grep __ZTINSt3__110shared_ptrIN10librevenge15RVNGInputStreamEE27__shared_ptr_default_deleteIS2_S2_EE
> 0000000000006dd8 (__DATA,__const) weak private external __ZTINSt3__110shared_ptrIN10librevenge15RVNGInputStreamEE27__shared_ptr_default_deleteIS2_S2_EE
while libcdr erroneously does not use -fvisibility=hidden and generates
> $ nm -m workdir/UnpackedTarball/libcdr/src/lib/.libs/libcdr-0.1.a | grep __ZTINSt3__110shared_ptrIN10librevenge15RVNGInputStreamEE27__shared_ptr_default_deleteIS2_S2_EE
> 00000000000072b8 (__DATA,__const) weak external __ZTINSt3__110shared_ptrIN10librevenge15RVNGInputStreamEE27__shared_ptr_default_deleteIS2_S2_EE
The reason for that error is as follows:
workdir/UnpackedTarball/libcdr/configure.ac uses, among other things, the result
of
AX_GCC_FUNC_ATTRIBUTE([visibility])
when deciding whether to use -fvisibility=hidden. And the old ("serial 5")
workdir/UnpackedTarball/libcdr/m4/ax_gcc_func_attribute.m4 decides "no" if its
test compilation generates any warning output. But Clang on macOS generates
> conftest.cpp:34:56: warning: target does not support 'protected' visibility; using 'default' [-Wunsupported-visibility]
> int foo_pro( void ) __attribute__((visibility("protected")));
> ^
and lots of
> conftest.cpp:2:9: warning: macro is not used [-Wunused-macros]
> #define PACKAGE_NAME "libcdr"
> ^
(because of -Wunused-macros set for Clang in
solenv/gbuild/platform/com_GCC_defs.mk).
Same issue with external/libqxp, which would cause
> [LNK] Library/libwpftdrawlo.dylib
> ld: warning: direct access in function 'std::__1::__shared_ptr_pointer<librevenge::RVNGInputStream*, std::__1::shared_ptr<librevenge::RVNGInputStream>::__shared_ptr_default_delete<librevenge::RVNGInputStream, librevenge::RVNGInputStream>, std::__1::allocator<librevenge::RVNGInputStream> >::__get_deleter(std::type_info const&) const' from file 'workdir/UnpackedTarball/libcdr/src/lib/.libs/libcdr-0.1.a(CDRDocument.o)' to global weak symbol 'typeinfo for std::__1::shared_ptr<librevenge::RVNGInputStream>::__shared_ptr_default_delete<librevenge::RVNGInputStream, librevenge::RVNGInputStream>' from file 'workdir/UnpackedTarball/libqxp/src/lib/.libs/libqxp-0.0.a(QXPMacFileParser.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
<http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=commitdiff;
h=df0894ad1a8195df67a52108b931e07d708cec9a> "ax_gcc_func_attribute: Revise the
detection of unknown attributes", even though it was apparently meant to fix
something different, nicely fixes this Clang issue, making AX_GCC_FUNC_ATTRIBUTE
correctly detect support for visibility now.
When building with Clang on Linux, there is no -Wunsupported-visibility about
__attribute__((visibility("protected"))), but all the -Wunused-macros are
present as well, which caused all the AX_GCC_FUNC_ATTRIBUTE checks to be mis-
detected as "no" there, too.
There are more uses of AX_GCC_FUNC_ATTRIBUTE in
workdir/UnpackedTarball/libcdr/configure.ac and
workdir/UnpackedTarball/libqxp/configure.ac, and there are many more
workdir/UnpackedTarball/*/m4/ax_gcc_func_attribute.m4 in other external projects,
all of which may cause similar AX_GCC_FUNC_ATTRIBUTE mis-detections. However,
they do not cause any noticeable traces like the "direct access" ld warning here,
so I left those alone for now. (Ultimately, all the upstream external projects
should probably deploy the latest version of ax_gcc_func_attribute.m4 from
<http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;
f=m4/ax_gcc_func_attribute.m4>.)
Change-Id: Ia0560cace770ec7da9ee390566a01a5c592f9209
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/109774
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Also made it necessary to adapt two places in libcdr and libebook
that used UBool TRUE which is gone now to use standard true
instead.
Change-Id: I1c1df3030f8b883bec6045756907ee0b78060382
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105964
Tested-by: Jenkins
Reviewed-by: Eike Rathke <erack@redhat.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>
Opening cdr/fdo53278-4.cdr as obtained by
bin/get-bugzilla-attachments-by-mimetype (i.e., the attachment at
<https://bugs.documentfoundation.org/show_bug.cgi?id=53278#c14>) under
-fsanitize=undefined causes
> CDRPath.cpp:821:34: runtime error: -173.908 is outside the range of representable values of type 'unsigned int'
> #0 in libcdr::CDRPath::writeOut(librevenge::RVNGString&, librevenge::RVNGString&, double&) const at workdir/UnpackedTarball/libcdr/src/lib/CDRPath.cpp:821:34 (instdir/program/../program/libwpftdrawlo.so +0x2380015)
> #1 in libcdr::CDRContentCollector::_lineProperties(librevenge::RVNGPropertyList&) at workdir/UnpackedTarball/libcdr/src/lib/CDRContentCollector.cpp:1118:17 (instdir/program/../program/libwpftdrawlo.so +0x2090b54)
> #2 in libcdr::CDRContentCollector::_flushCurrentPath() at workdir/UnpackedTarball/libcdr/src/lib/CDRContentCollector.cpp:240:5 (instdir/program/../program/libwpftdrawlo.so +0x2070a9e)
> #3 in libcdr::CDRContentCollector::collectLevel(unsigned int) at workdir/UnpackedTarball/libcdr/src/lib/CDRContentCollector.cpp:563:5 (instdir/program/../program/libwpftdrawlo.so +0x209243d)
> #4 in libcdr::CDRParser::parseRecord(librevenge::RVNGInputStream*, std::vector<unsigned int, std::allocator<unsigned int> > const&, unsigned int) at workdir/UnpackedTarball/libcdr/src/lib/CDRParser.cpp:514:18 (instdir/program/../program/libwpftdrawlo.so +0x213bdff)
> #5 in libcdr::CDRParser::parseRecords(librevenge::RVNGInputStream*, std::vector<unsigned int, std::allocator<unsigned int> > const&, unsigned int) at workdir/UnpackedTarball/libcdr/src/lib/CDRParser.cpp:500:10 (instdir/program/../program/libwpftdrawlo.so +0x213b93f)
[...]
Change-Id: Ie73965851102689ebb7895d61edb3d32ff47c60c
Reviewed-on: https://gerrit.libreoffice.org/73181
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
(but which requires a little upstream master patch)
Change-Id: I4bea938c402b03d8b05b6e70694ecc0184544b81
Reviewed-on: https://gerrit.libreoffice.org/73179
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...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>
...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>
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
