Re: [boost] [config] BOOST_SYMBOL_VISIBLE on MinGW

Subject: Re: [boost] [config] BOOST_SYMBOL_VISIBLE on MinGW
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-04-19 23:42:34

Niall Douglas wrote
> On 16 Apr 2015 at 8:07, Robert Ramey wrote:
> 
>> Poking around config/compiler/gcc.hpp and config/plaform/w32.hpp It seems
>> to
>> me that this scheme things look OK - that is it looks that
>> BOOST_SYMBOL_VISIBILITY should be defined as
>> __attribute__((__visibility__("default")))
>> 
>> I'm also puzzled by the fact that the linker craps out only on this on
>> declaration.
>> 
>> Any help appreciated.
> 
> You're second guessing the established pattern for how to do symbol 
> visibility. 

How so?

> The established patterns were chosen for good reasons. 

I did look over the boost documentation on the usage of the
auto-link/visibility
macros along with the source code in config and the email chain which
discussed
all this in some detail.  Frankly, I've been able to find and explanation
of what "established patterns" are.

> In  particular, the established pattern works as expected on Mingw, MSVC 
> and all other compilers. Per member function overrides are 
> particularly unwise to do.

I don't see how to avoid this if one needs to use BOOST_SYMBOL_VISIBLE
for exported class declarations to satisfy gcc.

Hmm - things have worked well for many years for mdvc and Borland 
(now obsolete). I made a few changes to support gcc visibility and
after a couple of hiccups, things work with Gcc as well.  Seems to me
that mingw is some combination of compiler=gcc and platform = win32.
I'd be curious to hear from anyone who might have had a similar issue
and resolved it.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/config-BOOST-SYMBOL-VISIBLE-on-MinGW-tp4674531p4674597.html
Sent from the Boost - Dev mailing list archive at Nabble.com.