external/libcdr/UnpackedTarball_libcdr.mk |1 +
external/libcdr/ax_gcc_func_attribute.m4.patch | 11 +++
external/libqxp/UnpackedTarball_libqxp.mk |3 +++
external/libqxp/ax_gcc_func_attribute.m4.patch | 11 +++
4 files changed, 26 insertions(+)
New commits:
commit 05aedcba6672979d317b540bbfa74f5c9b409402
Author: Stephan Bergmann
AuthorDate: Thu Jan 21 23:19:20 2021 +0100
Commit: Stephan Bergmann
CommitDate: Fri Jan 22 07:31:49 2021 +0100
Fix use of -fvisibility=hidden with Clang in external/libcdr,
external/libqxp
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::__shared_ptr_default_delete, std::__1::allocator
>::__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::__shared_ptr_default_delete' 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
> 6dd8 (__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
> 72b8 (__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::__shared_ptr_default_delete, std::__1::allocator
>::__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::__shared_ptr_default_delete' 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.
"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 de
