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@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users