Re: [boost] [config] GCC symbol visibility across shared libraries

Subject: Re: [boost] [config] GCC symbol visibility across shared libraries
From: Beman Dawes (bdawes_at_[hidden])
Date: 2010-05-19 18:03:23

On Wed, May 19, 2010 at 2:16 PM, Jürgen Hunold <juergen.hunold_at_[hidden]> wrote:
>...
>> In addition to that change, I've moved the definitions from win32.hpp
>> into the specific compilers involved. These visibility macros are
>> compiler extensions to C++, and are starting to show up in platforms
>> other than Windows.
>
> The rationale for the win32.hpp was that _every_ compiler has to support
> ___declspec on this platform.

Every compiler that wants to be compatible with other current Windows
compilers will support ___declspec today, but the introduction of
attribute syntax in C++0x may mean changes in the future. Also, some
past compilers used on Windows didn't support ___declspec, and
Microsoft has changed the spelling of the syntax at least once.

I also have more dislike for having to change the platform headers
when compilers change than the other way around. I don't have any way
to test some of the platform headers easily either.

> I don't know if clang on linux supports __declspec or uses gcc __attribute.
> So I think win32.hpp + platform compiler setup might be the way.
> Or even unix.hpp with __attribute usage for all gcc compatible compilers.
> Else we have a high redundancy defining the same macros in every compilers
> header.

I'm still not convinced.

>> I've also edited the docs changes somewhat.
>
> Thanks, writing docs is a weak point (at least for me ;-))
>
>> So far, I've only made changes to Boost.System. See the attached.
>> (I've also made a lot of tweaks to Boost.System tests, but those are
>> of limited interest so aren't included in the attached diff.)
>
> looks good.
>
>> Unless there are objections, I'll commit these to trunk, and wait
>> until tests have cycled for several days before doing anything with
>> other libraries. We will want to alert developers of other libraries,
>> as some of them will prefer to make their own changes. Others will be
>> happy if someone else makes the changes.
>
> My only objection is the redundancy introduced by moving the logic out of
> win32.hpp. I don't like lots of identic definitions flying around.

What do others think?

--Beman