On 04/24/2015 01:35 AM, Robert Ramey wrote:
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.
From what I understand, this is by design. Instead of thinking about symbol import/export as "how the compiler I'm using behaves," it's more of a target platform issue. When you're compiling a shared library for Linux, the resulting ELF file exports all symbols by default. Windows DLLs, however, are the opposite: they only export symbols that are explicitly marked (e.g. "dllexport" on MSVC). There are gcc flavors that target each platform, so gcc on Linux doesn't need any symbol annotation, while mingw requires that the symbols you want to export be marked as such. I'm not a Windows development expert at all, but I *think* that if you treat mingw like you treat MSVC with regard to symbol export/import, then it should work. Jason