On 03/13/2016 07:21 PM, julien2412 wrote:
On MacOs 10.11 with master sources updated today (with lode +
enable-dbgutil) + clean build I noticed this:
[build DEP] LNK:Library/librptxmllo.dylib
[build LNK] Library/librptxmllo.dylib
ld: warning: direct access in
std::__1::__shared_ptr_pointer<std::__1::vector<SdPage*,
std::__1::allocator<SdPage*> >*,
std::__1::default_delete<std::__1::vector<SdPage*,
std::__1::allocator<SdPage*> > >,
std::__1::allocator<std::__1::vector<SdPage*,
std::__1::allocator<SdPage*> > > >::__get_deleter(std::type_info const&)
const to global weak symbol typeinfo for
std::__1::default_delete<std::__1::vector<SdPage*,
std::__1::allocator<SdPage*> > > means the weak symbol cannot be
overridden at runtime. This was likely caused by different translation units
being compiled with different visibility settings.
[build CMP] reportdesign/util/rptui
[build CMP] reportdesign/util/rptxml
[build BIN] reportdesign
[build MOD] reportdesign
[build DEP] LNK:Library/libswlo.dylib
[build LNK] Library/libswlo.dylib
[build CMP] sd/util/sd
[build DEP] LNK:CppunitTest/libtest_sd_uimpress.dylib
[build LNK] CppunitTest/libtest_sd_uimpress.dylib
ld: warning: direct access in
std::__1::__shared_ptr_pointer<std::__1::vector<SdPage*,
std::__1::allocator<SdPage*> >*,
std::__1::default_delete<std::__1::vector<SdPage*,
std::__1::allocator<SdPage*> > >,
std::__1::allocator<std::__1::vector<SdPage*,
std::__1::allocator<SdPage*> > > >::__get_deleter(std::type_info const&)
const to global weak symbol typeinfo for
std::__1::default_delete<std::__1::vector<SdPage*,
std::__1::allocator<SdPage*> > > means the weak symbol cannot be
overridden at runtime. This was likely caused by different translation units
being compiled with different visibility settings.
Perhaps it's been there since long time, I just wondered if it was something
that could be easily fixed.
Happens when linking Library/libsdlo.dylib and
CppunitTest/libtest_sd_uimpress.dylib. (You should consider running
make with -O, so that output from a parallel make can be meaningfully
interpreted.)
The facts are that class SdPage is marked as SD_DLLPUBLIC (in
sd/inc/sdpage.hxx), and that the (non-inline) definition of member
function __get_deleter of class template std::__1::__shared_ptr_pointer
(in libc++'s <memory>) uses typeid.
Looking at the warning generated when linking Library/libsdlo.dylib,
what can be observed is:
(1) The "typeinfo for
std::__1::default_delete<std::__1::vector<SdPage*,std::__1::allocator<SdPage*>>>"
data symbol is exported from libsdlo.dylib. Probably makes sense, given
SdPage is SD_DLLPUBLIC.
(2) The
"std::__1::__shared_ptr_pointer<std::__1::vector<SdPage*,std::__1::allocator<SdPage*>>*,std::__1::default_delete<std::__1::vector<SdPage*,std::__1::allocator<SdPage*>>>,std::__1::allocator<std::__1::vector<SdPage*,std::__1::allocator<SdPage*>>>>::__get_deleter(std::type_info
const&)const" text symbol is not exported from libsdlo.dylib. Somewhat
odd, given SdPage is SD_DLLPUBLIC, but maybe -fvisibility-inlines-hidden
(as used by LO) causes Clang to also hide implicit instantiations of
non-inline template member functions.
(3) The code generated for (2)'s use of typeid loads the value of (1)
directly (relative to %rip) instead of via GOT. That causes the
warning, and is rather odd.
Not sure who's at fault here.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
