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.
