Mike Stump wrote:
> 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.
Yes, I understand that's what you're saying. The evidence I cited suggested
otherwise (but see below).
> 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.
I'm not interested in how Xcode handles -fvisibility; I never said I was. I'm
simply interested in how g++ handles it, when invoked from the command line.
>> 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.
I only want to be helped to my satisfaction ;-)
> We do really want to help you understand the issues involved.
If you really were trying to be helpful, and you thought a correct answer
depended on my providing more information, you would have described what
additional information was required.
The question I'm interested in is the one I originally asked.
>> 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?
And I don't care.
> 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.
Let's go back a bit:
Mike Stump wrote:
> Jonathan Turkanis wrote:
> > 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.
If the implication is that users should grep the source code before asking
questions, that's not a reasonable expectation.
> This mailing list is for the
> developers of gcc.
You didn't answer my question on gcc-help, either.
>> > 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.
Okay, I'll rephrase it: "now that you have a hint, would you please tell me what
the hint is?" (but you've already answered it now)
>> But the example discussed there used no visibility attributes and no
>> -fvisibility options.
>
>
>
> Prove it.
As I said:
Jonathan Turkanis wrote:
> I don't have time to verify the assertions made in that thread
> [http://article.gmane.org/gmane.comp.lib.boost.build/10072] -- the
> book went into production in August -- but I trust the author [Mat
> Marcus] and he seems to have conducted some careful experiments.
Looking into it further, I've found:
From Bugzilla Bug 23628:
> ------- Additional Comment #9 From Mat Marcus 2005-08-29 20:44 [reply]
> Sorry, I was a bit sloppy--I didn't remove all intermediate layers
> from my test environment. I will explore this further. In any case,
> if I explicitly invoke g++ -fvisibility=hidden t.cc && ./a.out the
> "Oops" case is encountered.
So part of Mat Marcus's original post was wrong. Still, there seem to be
some serious issues with -fvisibility=hidden, as discussed in Bugzilla. Part of
it seems to be a libstdc++ problem.
>> > 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.
I answered your question as if you had said "not exporting a class" instead of
"not exporting the class", because you didn't seem to be refering to a
particular class. I guess I should have just asked what class your were talking
about.
--
Jonathan Turkanis
www.kangaroologic.com
