This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: On which platforms is -fvisibility supported?


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?"

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


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


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.

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]