Re: On which platforms is -fvisibility supported?

[Jonathan Turkanis <technews at kangaroologic dot com>]

Geoffrey Keating wrote:

> Jonathan Turkanis <technews@kangaroologic.com> writes:
>
>> Geoffrey Keating wrote:
>>
>>> Jonathan Turkanis <technews@kangaroologic.com> writes:


>>>> If you tell us what the real question is, maybe we can answer that one.
>>
>>
>> To me, that sounds like an insult: why do you think I wouldn't ask the
>> "real" question? But I'll give you the benefit of the doubt and assume
>> you mean something as yet unspecified.


> I think the real question you meant to ask was "I am writing a book.
> I'm trying to decide what recommendations to use with respect to
> -fvisibility.  Is it widely supported?  Where?  And do you have any
> other suggestions as to what to recommend?"


I'm getting tired of this. You assumed I'm must have meant something else than 
what I plainly asked; once I mentioned that I was writing a book, you realized I 
really meant what I said.

There's no point trying to retrospectively justify your obfuscation.

> [Please don't think that I was trying to insult you.  Finding the real
> question to ask is very hard, but is often much more useful than
> finding an answer---a lot of the time, by the time you've found the
> question, the answer is obvious.]


I feel like I've finally come of age. Thanks.

> So, the first thing you should know is that all -fvisibility options
> are supported when you are using a recent GNU assembler with ELF.
> -fvisibility=default is supported everywhere. -fvisibility=hidden is
> supported on all Darwin platforms (but the other two settings are not).


That wasn't so hard now, was it?

> Something that you should understand, though, is that
> -fvisibility=hidden is not an optimisation option.  It changes the
> meaning of a program.  The change it makes is that functions,
> variables, and types defined in one dynamic library are different to
> functions, variables, and types of the same name defined in a
> different dynamic library; so they have different addresses, different
> contents, and different typeinfo.


I under this.

> Sometimes, this is exactly what you want, and other times it isn't.
> If it's mostly what you want but not completely, you can use the
> #pragma and the attribute to control it at a finer level; the option
> only sets the default for the #pragma, and the #pragma in turn only
> sets the default for the attribute.  When you build Boost as a shared
> library, that's an example of where you don't want this behaviour, at
> least for certain types defined in the Boost headers.  When you build
> it as a static library, that's an example of where you probably do
> want this behaviour.


As I mentioned in my reply to Mike Stump, the Boost problems apparently occur 
even if none of the visibility options, pragmas or attributes are used.

--
Jonathan Turkanis
www.kangaroologic.com