Subject: Re: [boost] [config] gcc,msvc,mingw visibility
From: Jason Roehm (jasonr_at_[hidden])
Date: 2015-04-24 07:30:11
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
> uses the windows attributes in it's gcc compiler - all versions tested by
> So the test matrix showed everything fine except for MinGW. So I haven't
> able to reconcile all the macros in this gcc/win32 combination. I looked at
> the other libraries. They support MSVC export/inport - but don't enable gcc
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk