ld: warning: direct access (MacOs)

[Stephan Bergmann]

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.