Boost logo

Boost :

Subject: Re: [boost] [config] gcc,msvc,mingw visibility
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-04-24 01:35:43

... snip ...

OK, I pretty much understood this you described. Though You've certainly
it better than I have. I've always had this working under msvc but have
in extending it gcc. It wasn't a huge deal and everything went more or less

> 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
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.

I took another stab at it but this broke my windows links on the test

I'm still on it.

View this message in context:
Sent from the Boost - Dev mailing list archive at

Boost list run by bdawes at, gregod at, cpdaniel at, john at