On which platforms is -fvisibility supported?

Jonathan Turkanis technews@kangaroologic.com
Thu Sep 22 04:43:00 GMT 2005


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







More information about the Gcc mailing list