On 22/03/2016 15:04, Stephan Bergmann wrote:
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.
This one appears to have healed itself meanwhile, at least I don't get
it with my recent local master builds with Clang 12 trunk on macOS ARM64
and x86-64. And the last remaining occurrences of any "ld: warning:
direct access..." I spotted with those builds should be fixed with
<https://git.libreoffice.org/core/+/db1561f0510a179045ccea857f9386af83af729f%5E!/>
"Build compilerplugings code with -fvisibility-inlines-hidden" and
<https://git.libreoffice.org/core/+/05aedcba6672979d317b540bbfa74f5c9b409402%5E%21>
"Fix use of -fvisibility=hidden with Clang in external/libcdr,
external/libqxp".
Let me know if you see any other of those "ld: warning: direct
access...", they might point at underlying issues that are worth fixing.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
