------- Additional Comments From s_gccbugzilla at nedprod dot com 2005-09-01 10:42 ------- Vladimir Prus Wrote:
> It's is mess, but I hope that we don't just agree on *that*. The situation > is that the whole -fvisibility thing does not work reliably for C++ > dynamic libraries which is rather bad. I wouldn't go /that/ far - if you know what you're doing, it's completely reliable. The problem is that it involves a lot of knowledge of ELF internals which most people using GCC don't have and IMHO, shouldn't need to have. The problem I see here is that Andrew knows the internals of GCC extremely well, and so to him IMHO he can't see why users are having such a problem. > You might be formally right, but what about practical consequences? Unless > *all* libraries I use have push/pops in *every single header*, using > -fvisibility for my own library can result in crash. So for a large > application you'd need to get authors of all used libraries to "fix" them! > Note that even libstdc++ does not have this at the moment. This makes > -fvisibility just useless. One of our overriding goals when making this patch was to AVOID patching any existing library headers! See PR 9283 and PR 15000. The way I see it is that GCC's current behaviour interferes with the ODR. If you define a type in one compilation unit and then again in another, and you compare the two, currently it works if those compilation units are in the same shared object but it fails if they are in different shared objects. This to me is confusing at best, and causes hard-to-find bugs at worst. It also isn't compatible with MSVC's behaviour which was also one of the original goals of the patch - to allow existing MSVC DLL macro support to be reused in GCC. Now I raised this originally back in the day, but I was told that the performance penalty of memcmp()-ing symbols was too much - even though MSVC does just this and I haven't seen many complaints about its typeinfo performance. However, I am very certain that so long as it remains this way, you're just going to get more and more people complaining in here. So how about this - how about we get GCC to emit a special linkonce symbol called say __gcc_linkonce_nondefaultvisibility if a compilation unit uses non- default visibility? And if that symbol is present, the GCC runtime uses memcmp() instead of address comparison during typeinfo work - if I remember, there's about two or three places where code would need altering. This solves the problem, and keeps everyone happy. If people agree, I could contribute a little to this patch. Cheers, Niall -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23628
