On which platforms is -fvisibility supported?

[Mike Stump]

On Friday, September 16, 2005, at 10:19  AM, Jonathan Turkanis wrote:
> > I think I can give you an answer which is completely correct and yet
> > completely useless:  -fvisibility=default is supported on every 
> platform.
>
> Thank you -- it's not completely useless.

It is.

> I don't want to recommend that users supply -fvisibility=default

Telling users to supply that flag is useless.  It is the default.  
Conceptually, you would want to tell them to not use 
-fvisibility=hidden.

>  if it will result in an 'unrecognized option' error on some platforms.

> I sense a joke lurking here.

We are confounded as to why you would want to tell a users to specify a 
flag that is the default.  After reading to the end of your email, I 
now understand your question better.

> > As Mike says,
>
> >> If you tell us what the real question is, maybe we can answer that 
> one.
>
> To me, that sounds like an insult

No, we just have enough experience and knowledge, and we actually do 
want to help you, but we know enough to know you are hiding the real 
question from us, and we know that you need the real answer, but we 
can't give it to you, since we don't have the question.

> : why do you think I wouldn't ask the "real" question?

Experience.

> The docs for -fvisibility say: "Set the default ELF image symbol 
> visibility to the specified option —- all symbols will be marked with 
> this unless overridden within the code...."

You can read this without the word ELF and is looses nothing, in fact, 
it would be more accurate.

> So it seems a fair question to ask where -fvisibility is supported. An 
> answer that isn't "completely useless" would be appreciated.

M-x grep VISIBILITY tells you the answer.  The answer, is precisely on 
darwin, and all platforms whose in tree gas assembler is elf whose 
version is 2.13 and above or if the assembler accepts:

	.hidden foo

without returning a non-zero return code from the assembler and the 
linker is 2.13 and above if in tree, otherwise as long as the linker 
isn't older than 2002-04-04 or people mussed up the version string of 
the linker or is 2.12.0 or older we suppose symbol visibility.

Now, did that precisely answer your question?

Compare that with, every interesting platform now supports visibility 
default/hidden.

> I'm trying to decide what recommendations to make with repect to 
> -fvisibility for a forthcoming O'Reilly C++ book.

Gosh, now we have a hint at the real question.  I suspect the answer 
is, go ahead and use it

> At first it looked like a nice way to enable Windows-style exporting 
> of symbols from dynamic libraries on some UNIX/Linux platforms. Now it 
> appears that there may be some serious problems with it, at least as 
> currently implemented. See e.g., 
> http://article.gmane.org/gmane.comp.lib.boost.build/10072 and 
> http://article.gmane.org/gmane.comp.lib.boost.build/10110. Those 
> threads were also the first indication I had that -fvisibility was 
> supported on some non-ELF platforms.
>
> I don't have time to verify the assertions made in that thread -- the 
> book went into production in August -- but I trust the author and he 
> seems to have conducted some careful experiments. I'm now inclined 
> just to say that the option, together with the attribute, offered the 
> possibility of Windows-style exporting on some (unspecified) 
> platforms, but that initial implementation is buggy; 
> -fvisibility=default should be specified everywhere, until further 
> notice.

Ah, now we can start getting to the meat of the question.

Buggy?  I think I might disagree with that assessment if you are 
referring to the inability to catch hidden types across the hidden 
boundary.

Anyway, the real issue boils down to some rather simple concepts.  
Suppose someone has:

class A {
};

in one part of their program and:

class A {
};

in another part of their program.  The question is, are they the same?  
The answer in non-shared library, non-dlopen(), trivial systems, yes.  
This is visibility default.  When people want them to be different, 
then one erects a fence around one or the other, to prevent them from 
being the same.  visibility hidden, in any of its forms, does that.

The problems the boost people saw were, they wanted an A, that was 
across the fence to be the same as the other A on the near side of the 
fence, this is illogical, I might claim, and does not indicate a buggy 
compiler.

For you to defend it as a buggy compiler, you'd have to explain by what 
mechanism you want to mark the two As as being separate.  My claim 
would be that visibility hidden is exactly that mechanism.

Now, if you are asking how to mark the types as default when 
-fvisibility=hidden is used, gosh, could have sworn there was a way to 
do it, but someone seems to have broken every incantation I tried.  :-( 
  That to me seems to be a bug.

__attribute__ ((visbility("default"))) class A {
   virtual void foo();
};

A a;

void A::foo() {
}

and

class  __attribute__ ((visbility("default")))  A {
   virtual void foo();
};

A a;

void A::foo() {
}

seem like they both should work and when -fvisibility=hidden is used, 
it should cause the rtti information/vtable information and so on to 
not be hidden.

Do you know of off hand where Microsoft puts the magic string to export 
the class?  Do they even have a concept of not exporting the class?