On which platforms is -fvisibility supported?
Hi, I've asked this question twice at gcc-help, but got no response. On which platforms is the -fvisibility option supported? The GCC docs here (http://tinyurl.com/99wc8) suggest that it is a subset of ELF platforms. Is that correct? -- Jonathan Turkanis www.kangaroologic.com
Re: On which platforms is -fvisibility supported?
Mike Stump wrote: > On Sep 14, 2005, at 8:59 AM, Jonathan Turkanis wrote: > >> I've asked this question twice at gcc-help, but got no response. >> On which platforms is the -fvisibility option supported? > autoconf will answer this question for you, please use it. Do you mean I should run autoconf on each platform where GCC is available to get an answer? I'm sure you don't think this is a practical suggestion, which leaves me wondering what you really mean. > Giving you an answer strikes me as dangerous. Why? > If you tell us what the real question is, maybe we can answer that one. First tell me what your real answer is. > ELF, darwin would be my approximate answer, if you had to have one. You don't have to have one. But a non-answer is worse than no answer. >> The GCC docs here (http://tinyurl.com/99wc8) suggest that it is a subset of ELF platforms. Is that correct? > > > > No. It also works on darwin, darwin is not an ELF platform. Then the documentation is seriously misleading. -- Jonathan Turkanis www.kangaroologic.com
Re: On which platforms is -fvisibility supported?
Geoffrey Keating wrote: > Jonathan Turkanis <[EMAIL PROTECTED]> writes: >> On which platforms is the -fvisibility option supported? The GCC docs >> here (http://tinyurl.com/99wc8) suggest that it is a subset of ELF >> platforms. Is that correct? > 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. I don't want to recommend that users supply -fvisibility=default if it will result in an 'unrecognized option' error on some platforms. > (What, that wasn't the flag you were planning to use?) I sense a joke lurking here. > 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: 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. 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" This seems consistent with option being recognized only on ELF platforms, with it being recognized everywhere but ignored on non-ELF platforms, with it being supported everywhere with analogous semantics to those described in terms of ELF visibility, or some mixture of the the these scenarios. To further cloud the issue, the docs refer to an article which seems to be refering only to ELF platforms, and the dos for the visibility attribute say that not all ELF targets support it. So it seems a fair question to ask where -fvisibility is supported. An answer that isn't "completely useless" would be appreciated. I'm trying to decide what recommendations to make with repect to -fvisibility for a forthcoming O'Reilly C++ book. 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. -- Jonathan Turkanis www.kangaroologic.com
Re: On which platforms is -fvisibility supported?
Mike Stump wrote: > 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. It's advertised as the default, but the threads I cited in my last post suggest that in some cases specifying -fvisibility=default produces different results that not specifying any default visibility option, regardless of what the spec says (see below). > 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. I didn't mention recommending -fvisibility=default until *after* you made the remark to which I was responding. >> > 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, Give me a break! What am I trying to hide? Not that I'm writing a book. I've posted dozens of messages to various newsgroups in the course of my research, and I've mentioned the fact that I was writing a book whenever it was relevant ... or when people seem to be ignoring my questions. What's really going on is that you seem to have assumed I wasn't really asking what I plainly was asking. Below you actually give a pretty good answer to my original question. > 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. I'm tempted to ask "in what?", but I think I don't really want to know. >> 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. Okay. I'll try ignoring words here and there and see if improves the quality of the documentation. My guess is it can't hurt. >> 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. What are you grepping? > 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. Now that you have a hint, tell me what it is. > 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
Re: On which platforms is -fvisibility supported?
Geoffrey Keating wrote: > Jonathan Turkanis <[EMAIL PROTECTED]> writes: > >> Geoffrey Keating wrote: >> >>> Jonathan Turkanis <[EMAIL PROTECTED]> 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
Re: On which platforms is -fvisibility supported?
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
Re: On which platforms is -fvisibility supported?
Ian Lance Taylor wrote: Jonathan Turkanis writes: 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. That's pretty much it, yes. Many years of experience have shown us by tedious example that most people ask the wrong question. Sorry you got caught, and sorry you feel insulted. Your question was easy to write, but was one that only a couple of people would know how to answer off the top of their head. If you want to get a question answered by an expert, you have to make the effort to not seem like a random newbie. I'm sorry it has to be that way, but that's the reality of the net. Thanks. Lately I've been feeling like I'm being chased by a pack of wild dogs ;-) Ian -- Jonathan Turkanis www.kangaroologic.com
Re: On which platforms is -fvisibility supported?
Hank Kester wrote: On 9/22/05, Jonathan Turkanis wrote: >> > 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: If the implication is that users should grep the source code before asking questions, that's not a reasonable expectation. I think that expecting the author of an email to the mailing list for developers of a program to have at least taken a cursory glance at the source of said program is entirely reasonable. As I implied, this would be reasonable if the developers in question were responsive to questions on the user's list. Especially if the question regards how something in done in the source. It doesn't. -Hank K. Jonathan
Re: On which platforms is -fvisibility supported?
Mike Stump wrote: On Thursday, September 22, 2005, at 05:42 PM, Jonathan Turkanis wrote: 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. Yup, as expected. I'm glad we were able to get to the bottom of this and hopefully help you understand gcc better. You can call it "getting to the bottom of this" if you want -- it's only marginally related to my original question. -- Jonathan Turkanis www.kangaroologic.com
Re: On which platforms is -fvisibility supported?
Dave Korn wrote: > Original Message >> From: Jonathan Turkanis >> Sent: 23 September 2005 01:43 >> If the implication is that users should grep the source code before asking >> questions, that's not a reasonable expectation. > It is actually the _fundamental_ principle under which this particular > mailing list operates! Jonathan Turkanis wrote: > I've asked this question twice at gcc-help, but got no response. I didn't even get a sarcastic response! :-P The end result is that a *user* with a question about the documentation, must grep the souce. That's not a reasonable expectation. > cheers, > DaveK -- Jonathan Turkanis www.kangaroologic.com
Re: On which platforms is -fvisibility supported?
Robert Dewar wrote: Jonathan Turkanis wrote: Jonathan Turkanis wrote: > I've asked this question twice at gcc-help, but got no response. I didn't even get a sarcastic response! :-P Well there is no guaranteed response, given this is a volunteer activity. You can't complain if you don't get a response from the volunteer group (well you can complain, but no one is oblligated to pay any attention to your complaint). Obviously there's no guarantee. But don't tell me I can't complain. ;-) I'm a volunteer author and maintainer of several open source projects, and I never tell users to "use the source, Luke" if they have a question which should be answered in the documentation. GCC has a real problem in this area. The end result is that a *user* with a question about the documentation, must grep the souce. If you come to this mailing list, which is for gcc developers, that is part of the price of admission, this list is not for users, but for developers. That's not a reasonable expectation. It is for developers, and if you are not a developer, you are really in the wrong place. Break it down how you like; it's still true that it's not reasonable to expect a user with a question about the documentation to grep the source before asking. -- Jonathan Turkanis www.kangaroologic.com
