Re: ld: warning: direct access (MacOs)

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&lt;SdPage*,
> std::__1::allocator&lt;SdPage*> >*,
> std::__1::default_delete<std::__1::vector&lt;SdPage*,
> std::__1::allocator&lt;SdPage*> > >,
> std::__1::allocator<std::__1::vector&lt;SdPage*,
> std::__1::allocator&lt;SdPage*> > > >::__get_deleter(std::type_info const&)
> const to global weak symbol typeinfo for
> std::__1::default_delete<std::__1::vector&lt;SdPage*,
> std::__1::allocator&lt;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&lt;SdPage*,
> std::__1::allocator&lt;SdPage*> >*,
> std::__1::default_delete<std::__1::vector&lt;SdPage*,
> std::__1::allocator&lt;SdPage*> > >,
> std::__1::allocator<std::__1::vector&lt;SdPage*,
> std::__1::allocator&lt;SdPage*> > > >::__get_deleter(std::type_info const&)
> const to global weak symbol typeinfo for
> std::__1::default_delete<std::__1::vector&lt;SdPage*,
> std::__1::allocator&lt;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.