Re: [Boost-users] questions about visibility/dlls under mingw

Subject: Re: [Boost-users] questions about visibility/dlls under mingw
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-11-19 18:49:19

On 11/15/18 3:57 AM, John Maddock via Boost-users wrote:
> 
> On 15/11/2018 00:04, Robert Ramey via Boost-users wrote:
>> MINGW is the platform which runs gcc compilers under winsoze.
>>
>> I include all the visibility attribute in the "right" places with 
>> serialization build and tests.  This is looking like it's passing on 
>> all platforms EXCEPT MINGW.  I think MINGW uses the windows 
>> attributes, but I'm wonder if our boost setup uses the gcc macros. 
>> This would explain the bahavior I'm getting now.  But honestly I 
>> really have no idea. here's the link to the appveyor results:
>>
>> https://ci.appveyor.com/project/RobertRamey/serialization/builds/20309631
>>
>> Perhaps this is a config issue? or I'm doing wrong?  I'm loath to much 
>> with this just for this one platform.
> 
> I had a quick look, but I'm stuck.
> 
> 
> * I can reproduce with mingw-gcc-8.1
> 
> * Focussing on just one failing test - 
> test_no_rtti_polymorphic_text_archive I see:
> 
> ..\..\..\bin.v2\libs\serialization\test\test_no_rtti_polymorphic_text_archive.test\gcc-8.1.0s17\debug\test_no_rtti.o: 
> In
>  Â function `save_derived(char const*)':
> D:\data\boost\boost\libs\serialization\test/test_no_rtti.cpp:54: 
> undefined reference to `__imp__ZN20polymorphic_derived2C1Ev'
> 
> And others, but focussing on the first error, 
> __imp__ZN20polymorphic_derived2C1Ev is an exported default constructor 
> for polymorphic_derived2.
> 
> * If I build with b2 -d2 and capture the command lines, I can preprocess 
> polymorphic_derived2.cpp and check the declarations, and indeed I see:
> 
> class polymorphic_derived2 :
>  Â Â Â  public polymorphic_base
> {
>  Â Â Â  friend class boost::serialization::access;
>  Â Â Â  template<class Archive>
>  Â Â Â  __attribute__((__dllexport__)) void serialize(
>  Â Â Â Â Â Â Â  Archive &ar,
>  Â Â Â Â Â Â Â  const unsigned int
>  Â Â Â  );
>  Â Â Â  __attribute__((__dllexport__)) const char * get_key() const;
> public:
>  Â Â Â  __attribute__((__dllexport__)) polymorphic_derived2();
>  Â Â Â  __attribute__((__dllexport__)) ~polymorphic_derived2();
> };
> 
> and
> 
> __attribute__((__dllexport__))
> polymorphic_derived2::polymorphic_derived2(){}
> __attribute__((__dllexport__))
> polymorphic_derived2::~polymorphic_derived2(){}
> 
> So that all looks OK.  But,
> 
> * If I examine the object files with nm, I see symbols for 
> polymorphic_derived2 *without* the leading "__imp_" - ie regular 
> non-exported symbols.
> 
> 
> At this point I'm stumped.  Anyone else?

OK - due to some sleuthing on the part of one of the auxiliary 
maintainers of the boost serialization library, it's seems that the 
problem is that

BOOST_SYMBOL_IMPORT is not defined to be __attribute__((__dllimport__)) 
under MINGW and that is the source of the problem. It's totally 
plausible since gcc visibility attributes are only applied to exports 
and it seems that in moving to windows this rule is carried over.  So 
I'm thinking that BOOST_SYMBOL_EXPORT needs to be updated for a special 
case of MINGW.

Of course, this is subject to confirmation. Hope this is helpful.

It's also been mentioned that the rules for application of these 
attributes might be different for functions and variables.  The thought 
of this makes me ill.  I don't know if it's true, but it's one more 
thing to keep things interesting.

Robert Ramey
> 
> John.
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users