On which platforms is -fvisibility supported?

[Mike Stump]

On Wednesday, September 21, 2005, at 09:13  PM, Jonathan Turkanis wrote:
> > Telling users to supply that flag is useless.  It is the default.
>
> It's advertised as the default, but the threads I cited in my last 
> post suggest

The only time that it would matter is when the command line has on it a 
flag, such a -fvisibility=hidden, that alters the default.  Let me 
elaborate.  Various build systems (which have nothing to do with gcc) 
can alter command lines, insert build flags, alter build flags so so 
on.  For example, Xcode inserts -fvisibility=hidden.  In that 
environment, when that flag is passed to gcc, adding 
-fvisibility=default does indeed alter the behavior.  In this case, the 
option is just negating a previous option.  I think it makes more sense 
to tell people to turn off -fvisibility=hidden in their build 
system/Xcode, if that is the real issue.

> Give me a break! What am I trying to hide?

You aren't trying to hide anything.  But, what we've found is that your 
original question didn't contain enough details for us to help you to 
our satisfaction.  We do really want to help you understand the issues 
involved.

> What's really going on is that you seem to have assumed I wasn't 
> really asking
> what I plainly was asking.

That's correct.  For example, you didn't ask, does Xcode inject 
-fvisbility=hidden into some compilations?  That answer is yes.  Is 
that a possibly relevant detail, yes.  Might it aide you in 
understanding the issue, I'd hope so, which is why I provide the 
answer.  In short, at times, we feel it is better to understand your 
question in detail, so that we may provide you an answer.

> > M-x grep VISIBILITY tells you the answer.
> What are you grepping?

Why, the source code to gcc of course.  This mailing list is for the 
developers of gcc.

> > Gosh, now we have a hint at the real question.
>
> Now that you have a hint, tell me what it is.

I'm sorry, could you repeat the question.

> But the example discussed there used no visibility attributes and no
> -fvisibility options.

Prove it.  Paste the command line to the compiler from the log file.  
Show us the .ii file, the resulting .s file and the command line flags. 
  When you try, you will discover that something passed it, that, or 
during the link, someone crafted an export list that didn't include 
`enough' symbols.  The preceding answer doesn't take into account 
dlopen/bundles complexities.  Since no one has yet mentioned those 
sorts of things, I'll ignore those issues.

> The two A's should be the same unless requested otherwise, no?

Right (given default flags/no funny environment variables, no linker 
export lists, no bundles, no dlopens and so on...)

> > Do they even have a concept of not exporting the class?
>
> Not exporting is the default, isn't it?

Sorry, I would not want to claim to be a Windows expert.  If boost 
works across dll boundaries, and it isn't otherwise marked to export, 
then, my only guess would be that in fact it did export.