... snip ... OK, I pretty much understood this you described. Though You've certainly explained it better than I have. I've always had this working under msvc but have problems in extending it gcc. It wasn't a huge deal and everything went more or less smoothly.
Getting back to BOOST_SYMBOL_VISIBLE and MinGW, I'm not sure what effect it has there, but I think it should be close to none.
That is not my experience In any case, it should not export anything because it is not needed in the contexts where the macro should be used, and where exporting is needed MY_LIB_API should be used instead. Then again, there are multiple flavors of MinGW out there, including the legacy MinGW32 where some GCC versions were broken wrt exceptions and dynamic_casts (which used type info addresses, like on Linux). If you're having problems with such broken MinGW then you have my condolences; I don't think you can work around it without crippling the user's code (basically, you'll have to reimplement part of the compiler runtime). I would recommend using a more recent GCC and MinGW64 instead. I don't think that's it. The versions in the test matrix seem recent to me. BUT when I cam up against MinGW I have serious problems. It seems that MinGW uses the windows attributes in it's gcc compiler - all versions tested by boost. So the test matrix showed everything fine except for MinGW. So I haven't been able to reconcile all the macros in this gcc/win32 combination. I looked at all the other libraries. They support MSVC export/inport - but don't enable gcc visibility=hidden so it seems that this is the first time the problem has come up. I took another stab at it but this broke my windows links on the test matrix. I'm still on it. -- View this message in context: http://boost.2283326.n4.nabble.com/config-gcc-msvc-mingw-visibility-tp467471... Sent from the Boost - Dev mailing list archive at Nabble.com.