[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #108 from funtoos at yahoo dot com 2007-05-28 17:47 --- but comments in bug 20218 say that its fixed in mainline, which means there was a fix put into gcc for hidden visibility. So, are both the fix from prerelease binutils and gcc mainline needed to fix this completely? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #107 from simon dot strandman at telia dot com 2007-05-28 11:49 --- (In reply to comment #106) > I haven't tried the fix in 20218. surprisingly, moving to binutils > 2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is > going on? how did the latest binutils bypass the bug 20218? > Probably because this bug is fixed in the prerelase binutils: http://sourceware.org/bugzilla/show_bug.cgi?id=3666 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #106 from funtoos at yahoo dot com 2007-05-28 05:16 --- I haven't tried the fix in 20218. surprisingly, moving to binutils 2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is going on? how did the latest binutils bypass the bug 20218? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #105 from pluto at agmk dot net 2007-05-28 05:01 --- (In reply to comment #104) > kdelibs doesn't link with gcc-4.2.0 with hidden visibility. you need a path for pr20218. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #104 from funtoos at yahoo dot com 2007-05-28 04:15 --- kdelibs doesn't link with gcc-4.2.0 with hidden visibility. It compiles and links fine with gcc 4.1.2 with patch from Comment #86. That patch was included by gentoo till 4.1.2 and dropped because this bug is supposedly fixed in 4.2.0. I am having difficulty understanding it. How is it fixed if it doesn't even match the functionality provided by one of the earlier proposed patches? Or Is it that the kdelibs-3.5.[67] code needs to change for the new patch in GCC 4.2.0? Where is the problem? The message from kdelibs link is: -- /bin/sh ../libtool --silent --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -march=k8 -msse2 -msse3 -fforce-addr -pipe -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -Wl,-O1 -Wl,--enable-new-dtags -o libkhtml.la -rpath /usr/kde/3.5/lib64 -version-info 6:0:2 -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -Wl,--version-script=./libkhtml.map -L/usr/kde/3.5/lib64 -L/usr/qt/3/lib64 -L/usr/lib64libkhtml_la.all_cc.lo libkhtml_la.all_cpp.lo ./xml/libkhtmlxml.la ./html/libkhtmlhtml.la ./rendering/libkhtmlrender.la ./css/libkhtmlcss.la ./misc/libkhtmlmisc.la ecma/libkjs_html.la ./dom/libkhtmldom.la ../kparts/libkparts.la ../kdeprint/libkdeprint.la ../kutils/libkutils.la ../kwallet/client/libkwalletclient.la /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ./html/.libs/libkhtmlhtml.a(libkhtmlhtml_la.all_cpp.o): relocation R_X86_64_PC32 against `vtable for DOM::HTMLPreElementImpl' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[3]: *** [libkhtml.la] Error 1 make[3]: Leaving directory `/home/tmp/portage/kde-base/kdelibs-3.5.7/work/kdelibs-3.5.7/khtml' make[2]: *** [all-recursive] Error 1 - -- funtoos at yahoo dot com changed: What|Removed |Added CC||funtoos at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #103 from pinskia at gcc dot gnu dot org 2007-04-03 17:37 --- *** Bug 31459 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||rjarrett at mathworks dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #102 from pinskia at gcc dot gnu dot org 2007-02-22 23:58 --- *** Bug 30900 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||centi_riccardo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #101 from bkoz at gcc dot gnu dot org 2006-08-22 12:44 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #100 from bkoz at gcc dot gnu dot org 2006-07-28 04:57 --- Subject: Bug 19664 Author: bkoz Date: Fri Jul 28 04:57:34 2006 New Revision: 115790 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115790 Log: 2006-07-27 Benjamin Kosnik <[EMAIL PROTECTED]> PR libstdc++/19664 round 3 * include/Makefile.am (tr1_headers): Add hashtable_policy.h. * include/Makefile.in: Regenerate. * include/tr1/hashtable: Move policy classes into... * include/tr1/hashtable_policy.h: ... this. New. * src/globals_locale.cc: Move contents * src/locale_init.cc: ... to here, put in anonymous namespace. * src/Makefile.am: Remove globals_locale.cc. * src/Makefile.in: Regenerate. * src/locale.cc: Convert __gnu_internal to anonymous namespace. * src/debug.cc: Same. * src/ext-inst.cc: Same. * src/mt_allocator.cc: Same. * src/pool_allocator.cc: Same. * include/tr1/random: Convert std::tr1::_Private to anonymous namespace. * include/tr1/random.tcc: Same. * include/tr1/hashtable: Move ::Internal to std::tr1::detail and enclose bits that can actually be internal in in anonymous namespace. * include/tr1/unordered_set: Adjust explicit qualifications for namespace changes. * include/tr1/unordered_map: Same. * include/tr1/cmath: Convert __gnu_internal to nested detail namespace. * include/bits/cpp_type_traits.h: Move __type_type into anonymous namespace. * include/ext/rope: Change _Rope_constants to anonymous namespace. * include/ext/ropeimpl.h: Same. * src/ext-inst.cc: Same. Added: trunk/libstdc++-v3/include/tr1/hashtable_policy.h Removed: trunk/libstdc++-v3/src/globals_locale.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/bits/cpp_type_traits.h trunk/libstdc++-v3/include/ext/rope trunk/libstdc++-v3/include/ext/ropeimpl.h trunk/libstdc++-v3/include/tr1/cmath trunk/libstdc++-v3/include/tr1/hashtable trunk/libstdc++-v3/include/tr1/random trunk/libstdc++-v3/include/tr1/random.tcc trunk/libstdc++-v3/include/tr1/unordered_map trunk/libstdc++-v3/include/tr1/unordered_set trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/debug.cc trunk/libstdc++-v3/src/ext-inst.cc trunk/libstdc++-v3/src/locale.cc trunk/libstdc++-v3/src/locale_init.cc trunk/libstdc++-v3/src/mt_allocator.cc trunk/libstdc++-v3/src/pool_allocator.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #99 from bkoz at gcc dot gnu dot org 2006-07-20 23:37 --- Subject: Bug 19664 Author: bkoz Date: Thu Jul 20 23:37:27 2006 New Revision: 115632 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115632 Log: 2006-07-20 Benjamin Kosnik <[EMAIL PROTECTED]> Jakub Jelinek <[EMAIL PROTECTED]> PR libstdc++/19664 round 1 * acinclude.m4 (GLIBCXX_ENABLE_VISIBILITY): Check it. * configure.ac: Use it. * configure: Regenerate. * docs/html/configopts.html: Document it. * include/Makefile.am: Slip in to c++config. * include/Makefile.in: Regenerate. * include/bits/c++config (_GLIBCXX_VISIBILITY): New. (_GLIBCXX_BEGIN_NAMESPACE): Use it. (_GLIBCXX_END_NAMESPACE): Use it. (_GLIBCXX_BEGIN_NESTED_NAMESPACE): Use it. (_GLIBCXX_END_NESTED_NAMESPACE): Use it. * src/debug.cc: Mark __gnu_internal namespace with hidden visibility attribute. * src/ext-inst.cc: Same. * src/globals_io.cc: Same. * src/globals_locale.cc: Same. * src/ios_init.cc: Same. * src/locale.cc: Same. * src/mt_allocator.cc: Same. * src/pool_allocator.cc: Same. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/docs/html/configopts.html trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/bits/c++config trunk/libstdc++-v3/libmath/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.in trunk/libstdc++-v3/po/Makefile.in trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/debug.cc trunk/libstdc++-v3/src/ext-inst.cc trunk/libstdc++-v3/src/globals_io.cc trunk/libstdc++-v3/src/globals_locale.cc trunk/libstdc++-v3/src/ios_init.cc trunk/libstdc++-v3/src/locale.cc trunk/libstdc++-v3/src/locale_init.cc trunk/libstdc++-v3/src/mt_allocator.cc trunk/libstdc++-v3/src/pool_allocator.cc trunk/libstdc++-v3/testsuite/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #98 from pinskia at gcc dot gnu dot org 2006-07-20 22:01 --- *** Bug 28449 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||ph0enix at ngs dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #97 from bkoz at gcc dot gnu dot org 2006-07-19 02:56 --- Mine. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-01-29 15:32:29 |2006-07-19 02:56:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #96 from bkoz at gcc dot gnu dot org 2006-07-19 02:52 --- Created an attachment (id=11912) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11912&action=view) viz patch part one Hey Jakub. Here's a way to start in on this. This does two things: 1) adds default visibility attributes to namespace std namespace std::tr1 namespace __gnu_cxx 2) adds hidden visibility attributes to namespace __gnu_internal There are a couple of things I want to do in addition to this, but these can be added in later. (Such as move as much __gnu_internal into anonymous namespaces, consolidate various internal namespaces into anonymous namespaces or __gnu_internal, relocation tuning, consolidation of visibility schemes between libsupc++ and libstdc++). Testing on so_7 with namespace associations is in progress. tested x86/linux tested x86/linux CXXFLAGS="-fvisibility=hidden" (fails) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #95 from jakub at redhat dot com 2006-07-15 10:34 --- Can this be revisited now? namespaces now can have the visibility attribute, although it has to be present on each opening namespace. Guess sticking __attribute__((__visibility__("default"))) into _GLIBCXX_BEGIN_NAMESPACE and similar macros could do the trick. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #94 from pinskia at gcc dot gnu dot org 2006-04-26 02:13 --- *** Bug 26846 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||laszlo dot szakony at ||philips dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #93 from geoffk at geoffk dot org 2006-04-04 00:23 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 03/04/2006, at 4:57 PM, pinskia at gcc dot gnu dot org wrote: > --- Comment #92 from pinskia at gcc dot gnu dot org 2006-04-03 > 23:57 --- > Both PR 27000 and bug 26984 are reasons why push/pop will fail > currently. It's probably OK if the visibility you're pushing is 'default'. At least, it's no worse to push default than it would be to not push anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #92 from pinskia at gcc dot gnu dot org 2006-04-03 23:57 --- Both PR 27000 and bug 26984 are reasons why push/pop will fail currently. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||26984 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #91 from mueller at gcc dot gnu dot org 2006-03-14 09:24 --- well, of course, because your libstdc++ is compiled with the wrong (LSB incompliant btw) stdc++ allocator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #90 from pluto at agmk dot net 2006-03-13 20:17 --- with 4.1.1 snapshot + patches I get an arts crash today on my x86_64 box. Starting program: /usr/bin/artsd Program received signal SIGSEGV, Segmentation fault. 0x2af641d8 in __gnu_cxx::__mt_alloc >::allocate () from /usr/lib64/libartsflow.so.1 (gdb) bt #0 0x2af641d8 in __gnu_cxx::__mt_alloc >::allocate () from /usr/lib64/libartsflow.so.1 #1 0x2ba4a908 in std::_Deque_base >::_M_initialize_map () from /usr/lib64/libmcop.so.1 #2 0x2ba49145 in Arts::NotificationManager::NotificationManager () from /usr/lib64/libmcop.so.1 #3 0x2ba2660a in Arts::Dispatcher::Dispatcher () from /usr/lib64/libmcop.so.1 #4 0x0041c227 in main (argc=1, argv=0x7fe818f8) at artsd.cc:275 arts works fine with visibiliy feature disabled. $ gcc -v Reading specs from /usr/lib64/gcc/x86_64-pld-linux/4.1.1/specs Target: x86_64-pld-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-shared --enable-threads=posix --enable-languages=c,c++,fortran,objc,obj-c++,ada,java --enable-c99 --enable-long-long --enable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib64 --without-system-libunwind --enable-cmath --with-long-double-128 --with-gxx-include-dir=/usr/include/c++/4.1.1 --disable-libstdcxx-pch --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --with-qt4dir=/usr/lib64/qt4 --disable-libjava-multilib --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo --enable-java-awt=qt,gtk,xlib --enable-jni --enable-xmlj --enable-alsa --enable-dssi x86_64-pld-linux Thread model: posix gcc version 4.1.1 20060308 (prerelease) (PLD-Linux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #89 from pinskia at gcc dot gnu dot org 2006-02-11 17:14 --- *** Bug 26217 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||gcc at dave dot dribin dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #88 from geoffk at gcc dot gnu dot org 2005-12-15 23:41 --- This patch doesn't solve the vector issue, does it? It doesn't look like it, I would have expected it to need some C++ frontend changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #87 from pluto at agmk dot net 2005-12-06 17:05 --- current 4.1(+libstdc++ patch) works fine for PR21382 on amd64 and ppc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #86 from bero at arklinux dot org 2005-11-03 09:38 --- Created an attachment (id=10120) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10120&action=view) Updated version of the patch to apply on current SVN -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #84 from geoffk at geoffk dot org 2005-11-01 04:30 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 31/10/2005, at 7:59 PM, bkoz at gcc dot gnu dot org wrote: > Geoff, it's not as simple as just marking throwable types, all > typeinfo, etc. > I'm performing an audit, but it's stuff like local statics as well. > Right, I wasn't trying to say that just marking the throwable types would be a complete solution (for anyone), just that it was easy, clearly correct as far as it went, and it would reduce the problem. > This has to be done very carefully for a C++ library, which isn't > as clearly defined as C libraries that are already using this > feature (but that don't have to deal with vague linkage.) > Plus, we don't really know what it should mean yet. For instance, if everything is compiled with visibility hidden, and dylib A throws "vector", should that be catchable in dylib B? I can think of good arguments for "yes", "no", and "undefined", which I guess means that "undefined" should win. --- Comment #85 from geoffk at geoffk dot org 2005-11-01 04:30 --- Created an attachment (id=10094) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10094&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #83 from bkoz at gcc dot gnu dot org 2005-11-01 03:59 --- I agree Geoff, we should hold off on this for 4.1, and try to hit 4.2. If things get solid sooner, maybe this can be reconsidered. Adding this patch to 4.0.x is out of the question, it has the potential to change too many things. I am working on this general issue at the moment. So, I will reassign to me since Paolo suggested it. Geoff, it's not as simple as just marking throwable types, all typeinfo, etc. I'm performing an audit, but it's stuff like local statics as well. This has to be done very carefully for a C++ library, which isn't as clearly defined as C libraries that are already using this feature (but that don't have to deal with vague linkage.) I'll come up with a gcc bugzilla enhancement request for visibility attributes on namespaces this week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #82 from pcarlini at suse dot de 2005-11-01 02:21 --- To clarify: I have unassigned myself from this bug because I don't consider myself sufficiently competent in this area to evaluate all the possible trade- offs of the issue and don't want to block in any way the work of knowledgeable people, Geoff, for instance. Help is much appreciated. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
-- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #81 from geoffk at geoffk dot org 2005-10-31 23:29 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 31/10/2005, at 2:45 PM, mueller at kde dot org wrote: > --- Comment #80 from mueller at kde dot org 2005-10-31 22:45 > --- > - not hiding a symbols is better than the resulting issues when > hiding a symbol > which should be exported. for example right now the function > static pointer > pointing to libstdc++'s memory allocator is hidden, which causes > STL usages > to just randomly crash when used across linking boundaries. > crashing is worse > than the performance penality by exported symbols > I wasn't thinking so much of the performance penalty, but rather of the ABI impact. Suddenly, your dynamic library, which you thought had carefully controlled exports (maybe it shouldn't export any C++ interfaces of its own at all), is exporting a global C++ type, 'std::vector', which could conflict with any similarly-named- but-different type anywhere in a program that uses the library. Performance is also a concern, of course. > - of course just exporting those classes that *should* be exported > would be > much more clever. I just thought if its so difficult to get a > brain-dead > simple patch that makes everything work not getting applied within > 6 months > then the stripped-down just-exporting-what-is-really needed (which > requires > a lot of in-depth knowledge and a lot of testing) would need more > something > like 6 years to get applied. > > Anyway, I volunteer to help reducing the amount of exported classes > if thats > what makes you apply the patch. The current brute-force export-all > patch > fixes everything and is dead simple compared to such a "only export > what > is needed patch". > Well (after re-reading what the bug was originally about): - You'll notice that the bug is about things which are not defined in this library, which can't possibly include the things I'm concerned about above, since every part of std::vector must be defined in this library since nothing else knows about 'mytype'. So it's certainly possible to fix it. - But, I'm not sure that the front-end supports everything you'll need to mark all the right pieces. For instance, ctype has to be hidden, but ctype has to be not hidden. It would probably be easier to teach the front-end that "if I'm instantiating something, the resulting thing must have the most restrictive visibility of any of its parameters" than it would be to go around trying to put attributes on each little method. - If that's too hard to do in time for 4.1, we could at least fix the related problems for non-x86-64 systems, which have to do with the classes thrown as exceptions; it's not useful to compile them with hidden visibility, since they're passed between libraries. (They're mostly in libsupc++.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #80 from mueller at kde dot org 2005-10-31 22:45 --- - if its not safe for all architectures we'd already run into heaps of problems because both libsupc++ and libgcc2 already include similiar pragmas. - not hiding a symbols is better than the resulting issues when hiding a symbol which should be exported. for example right now the function static pointer pointing to libstdc++'s memory allocator is hidden, which causes STL usages to just randomly crash when used across linking boundaries. crashing is worse than the performance penality by exported symbols - of course just exporting those classes that *should* be exported would be much more clever. I just thought if its so difficult to get a brain-dead simple patch that makes everything work not getting applied within 6 months then the stripped-down just-exporting-what-is-really needed (which requires a lot of in-depth knowledge and a lot of testing) would need more something like 6 years to get applied. Anyway, I volunteer to help reducing the amount of exported classes if thats what makes you apply the patch. The current brute-force export-all patch fixes everything and is dead simple compared to such a "only export what is needed patch". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #79 from geoffk at geoffk dot org 2005-10-31 22:14 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 31/10/2005, at 10:37 AM, ismail at uludag dot org dot tr wrote: > --- Comment #78 from ismail at uludag dot org dot tr > 2005-10-31 18:37 --- > Paolo, this is surely a bug fix. Why can't it make it to 4.1 ? > Waiting for 4.2 > means that unpatched gcc's will suffer for more. > I don't think the problem is solved yet, is it? In addition to the question of whether the patch is actually safe for all architectures, there's also still the question of using standard library templates, like 'vector', on hidden types; this works now if you use - fvisibility=hidden, and it'd stop working if the patch was applied, so you'd just be trading one problem for another. Better I think to not make this change in 4.1, at least that can't introduce any regressions, and work on the problem for 4.2. However, maybe the problem would be much reduced if we marked some specific classes as not hidden: those which are thrown as exceptions. There are only a handful of them, so we could do that with just an attribute, and surely that would be safe. What do people think of that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #78 from ismail at uludag dot org dot tr 2005-10-31 18:37 --- Paolo, this is surely a bug fix. Why can't it make it to 4.1 ? Waiting for 4.2 means that unpatched gcc's will suffer for more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #77 from pcarlini at suse dot de 2005-10-31 16:59 --- Thanks Benjamin! Indeed, if you want to take care of this entire issue, you are welcome (just reassign)! In any case, I'm not sure whether it's suited for 4.1, at this point... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #76 from bkoz at gcc dot gnu dot org 2005-10-31 16:47 --- Created an attachment (id=10085) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10085&action=view) hidden visibility for __gnu_internal Without per-namespace visibility attributes, this is what we will have to do for the known internal parts of libstdc++. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #75 from pcarlini at suse dot de 2005-10-25 15:44 --- (In reply to comment #74) > furthermore I manually added push/pop macros to libstdc++ headers on a debian > system (which is broken regarding visibility support) and it made my testcase > pass. To be clear: I have nothing against adding those push/pop missing the middle-end fixes. But I want to be 100% sure that nothing breaks. Thus my plan: I will update the patch doing that for mainline and ask Roger (the most qualified person, apparently) before committing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #74 from mueller at kde dot org 2005-10-25 15:41 --- yes, well one reason for it is that several libs (e.g. libgcc2) already use push/pop visibility macros and it doesn't seem to harm. furthermore I manually added push/pop macros to libstdc++ headers on a debian system (which is broken regarding visibility support) and it made my testcase pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #73 from pcarlini at suse dot de 2005-10-24 09:14 --- (In reply to comment #72) > why is it pointless? just because it doesn't work on some target architectures > doesn't mean it doesn't work on most main archs. Are you really, really, sure that without patching the middle-end at all, only changing the libstdc++-v3 headers benefits some targets without any side effects? I'm not at all, given this tangle. Really, we want someone to work seriously on the various serious outstanding bugs of the machinery, please if you consider it useful in principle for your project ask the maintainers and the knowledgeable compiler people to work on it, I tried, but I failed, by and large. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #72 from mueller at kde dot org 2005-10-24 05:22 --- why is it pointless? just because it doesn't work on some target architectures doesn't mean it doesn't work on most main archs. I find it pointless that a patch isn't applied just because it doesn't work on some archs (while it doesn't additionally break anything on those archs because all *this* patch does is to *ensure* that hidden visibility is disabled) -- mueller at kde dot org changed: What|Removed |Added CC||mueller at kde dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #71 from pcarlini at suse dot de 2005-10-21 11:40 --- (In reply to comment #70) > whats the status of the patch? can we at least have the visibility push/pop > patch for libstdc++ in gcc 4.0.x branch? See comment #63: at this stage changing libstdc++ is pointless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #70 from mueller at kde dot org 2005-10-21 11:36 --- whats the status of the patch? can we at least have the visibility push/pop patch for libstdc++ in gcc 4.0.x branch? Marc: what is the reason this patch is rejected? sure its not a regression, but visibility support is entirely useless without visibility support in libstdc++. The push/pop part is not the ideal solution (as it basically disables visibility for libstdc++), but its a can't-break workaround for a very pressing bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Comment #69 from pinskia at gcc dot gnu dot org 2005-10-08 13:42 --- *** Bug 24272 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||lothar at tradescape dot biz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From geoffk at gcc dot gnu dot org 2005-08-29 22:21 --- There was a comment in here about making visibility control happen at the namespace level. How would this work with, say, 'vector'? I would expect that if -fvisibility=hidden is set, then this instantiation should also be hidden, because presumably 'mytype' is a type private to this object. If some other object defines a different 'mytype', it certainly shouldn't use the same 'vector' implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 20:57 --- *** Bug 23628 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mmarcus at emarcus dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-08-21 20:25 --- *** Bug 22185 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||pedro dot lamarao at mndfck ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-21 16:17 --- *** Bug 22587 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||debian-gcc at lists dot ||debian dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-14 16:59 --- *** Bug 22482 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||caolanm at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-07-06 10:40 --- > should i update the mainline patch? Well, thanks for the offer, but the real blocker is 20218, which cannot be fixed yet, because, basically, *all* the back ends need tweaking: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02226.html Probably, I should find a way to more effectively ping the maintainers... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From aj at suse dot de 2005-05-21 16:50 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: > Then, can it not be left disabled for 4.0.x as well? It could - but people do want to use it. This is a rather important improvement and people have been waiting for this feature to see it in production since some time now. Andreas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From mark at codesourcery dot com 2005-05-20 18:48 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations lanius at gentoo dot org wrote: > --- Additional Comments From lanius at gentoo dot org 2005-05-20 08:35 > --- > no workaround, the flag was just disabled on the affected architectures Then, can it not be left disabled for 4.0.x as well? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-05-20 09:03 --- FWIW, I agree, as far as the visibility issues are concerned (I don't want to say something more general): the issues are *long* standing, important projects are already using the features and nobody (almost ;) cares about the bugs in the existing implementation. This is BAD. Either we fix those bugs ASAP, everywhere the feature is present, or (we scrap away everything and/or advertise the feature itself as broken). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pluto at agmk dot net 2005-05-20 09:02 --- (In reply to comment #52) > Great! I forgot to thank you for all your testing efforts: thanks! (...) i'll test these fixes on alpha/sparc{32,64} too in near feature. i have machines but no time :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pluto at agmk dot net 2005-05-20 08:58 --- (In reply to comment #54) > Subject: Re: libstdc++ headers should have pop/push > of the visibility around the declarations > > bernie at develer dot com wrote: > > > It's not a regresion, but it causes KDE to miscompile > > with GCC 4.0.0. Could we apply it for 4.0 anyway? > > No; we confine ourselves to regressions. If it wasn't a regression, > there must be some workaround that KDE is using for previous releases > that it can continue to use here. kde-core team already blacklisted gcc-4.0.0 due to detected bugs. they'll probably do the same thing with incoming 4.0.x releases due to gcc's rules which block major bugfixes != regression fixes. there is no logic reason for making workarounds for valid c++ code and releasing buggy 4.0.x branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From lanius at gentoo dot org 2005-05-20 08:35 --- no workaround, the flag was just disabled on the affected architectures -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From mark at codesourcery dot com 2005-05-19 19:21 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations bernie at develer dot com wrote: > It's not a regresion, but it causes KDE to miscompile > with GCC 4.0.0. Could we apply it for 4.0 anyway? No; we confine ourselves to regressions. If it wasn't a regression, there must be some workaround that KDE is using for previous releases that it can continue to use here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From bernie at develer dot com 2005-05-19 10:00 --- (In reply to comment #49) > > Mark, is > > > > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html > > > > OK for mainline as well as 4.0? > > It's OK for mainline. It's not OK for 4.0 unless it's a regression. It's not a regresion, but it causes KDE to miscompile with GCC 4.0.0. Could we apply it for 4.0 anyway? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-05-18 15:45 --- Great! I forgot to thank you for all your testing efforts: thanks! I'm going to have a final look and commit the v3 bits. Then, strong of your test, I'm also going to ping again on gcc-patches the middle-end bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pluto at agmk dot net 2005-05-18 15:42 --- (In reply to comment #50) > Thanks a lot. And, as soon as "pluto" has finished testing the whole package > I will personally take care of the v3 bits. on powerpc OpenEXR builds/links fine too. finally it works on amd64/powerpc/ia32 with -fvisibility-inlines-hidden. these 3 patches stay with me :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-05-17 22:00 --- > One of HJ's patches is a middle-end patch, and I'm not sure I know > enough to review it. I'd have to start by researching the ELF spec, for > example, and we've found that various version of binutils have weird > behavior around weak/linkonce. So, I'm scared of that one. I understand, of course. Maybe, with your release manager and global maintainer hat, you can "officially" ask the intervention of a middle-end person? My point was also this one... > The front end patch is OK. Thanks a lot. And, as soon as "pluto" has finished testing the whole package I will personally take care of the v3 bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From mark at codesourcery dot com 2005-05-17 21:58 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations hjl at lucon dot org wrote: > --- Additional Comments From hjl at lucon dot org 2005-05-17 21:50 > --- > Mark, is > > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html > > OK for mainline as well as 4.0? It's OK for mainline. It's not OK for 4.0 unless it's a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-05-17 21:50 --- Mark, is http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html OK for mainline as well as 4.0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-17 21:47 --- Subject: Bug 19664 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-17 21:47:13 Modified files: gcc/cp : ChangeLog decl2.c Log message: 2005-05-17 H.J. Lu <[EMAIL PROTECTED]> PR C++/19664 * decl2.c (determine_visibility): Don't set visibility to hidden if it has been set explicitly by user. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4745&r2=1.4746 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.781&r2=1.782 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From mark at codesourcery dot com 2005-05-17 21:40 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations pcarlini at suse dot de wrote: > --- Additional Comments From pcarlini at suse dot de 2005-05-17 19:05 > --- > >>This patch looks sensible to me, but it should be approved by a V3 >>maintainer. > > > Thanks a lot Mark, I'll try to get to it soon. But, the real reason we don't > have those bits already is that there are outstanding front-end issues that > apparently nobody cares about. One of HJ's patches is a middle-end patch, and I'm not sure I know enough to review it. I'd have to start by researching the ELF spec, for example, and we've found that various version of binutils have weird behavior around weak/linkonce. So, I'm scared of that one. The front end patch is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pluto at agmk dot net 2005-05-17 21:39 --- (In reply to comment #44) I've tested PR19664 patch + updated PR20218 patch + v3 patch and they work fine on amd64. I'll test fixes soon on powerpc on testcase from PR21382 too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-05-17 19:05 --- > This patch looks sensible to me, but it should be approved by a V3 > maintainer. Thanks a lot Mark, I'll try to get to it soon. But, the real reason we don't have those bits already is that there are outstanding front-end issues that apparently nobody cares about. Can you possible have a look to my last summary of the situation: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00275.html ??? Notice that in the meanwhile HJ posted/attached an updated patch for 20218. Do we at least agree that these are real bugs? Who is in charge of maintaining this visibility stuff? I'm finding the situation wrt to those visibility issues a little puzzling: apparently is a nice feature that we all want, but, on the other hand, nobody pays attention to those long-standing bug reports. Sorry about the rant ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-05-04 17:15 --- *** Bug 21382 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-04-18 14:14 --- Hi Michael and thanks for asking: really, I'm lost in this tangle of front-end, back-end and library issues. When I'm back from Oxford really want to move the issue forward, somehow, asking all the knowledgeable people (besides doing myself the, rather trivial, it seems, library bits). In the meanwhile, if you are able to see clearly which front-end/back-end patches among all those proposed here and posted on gcc-patches are *definitely* improvements, please patronize and ping on gcc-patches... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From matz at suse dot de 2005-04-18 12:50 --- Oh, and just annotating the testcase with the visibility push/pop #pragma is not enough, probably because of the problem in the c++ frontend, HJ noted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From matz at suse dot de 2005-04-18 12:49 --- So, any progress on this whole issue? I don't see either the pragmas in the C++ headers, nor HJs changes to the c++ frontend (despite testcase) in CVS. Just for the record, I see these problems (linkproblem with test from comment #11) also on ppc and ppc64, so it's not just a target dependend problem. On ppc64 it's an unresolvable R_PPC64_REL24 relocation, and on ppc it's simply an undefined reference to the std::string ctor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-02-27 03:54 --- There are 3 bugs here: 1. libstdc++ should have pop/push of the visibility. 2. C++ should support pop/push of the visibility. 3. Gcc should emit ".hidden foo" when foo is marked hidden, defined or not. Patches for #2 are at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00287.html I opened a bug for #3, bug 20218. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From giovannibajo at libero dot it 2005-02-26 23:45 --- HJL: would you please open a different bug report for the x86-64 issue and link it to this bug? Benjamin: can you open a different enhancement proposal about supporting the visibility attribute at namespace-level? Anyway, I think the correct way to go for 4.0 is to use the pragmas. A patch against the 4.0 branch would be much appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From bkoz at gcc dot gnu dot org 2005-02-25 22:40 --- Personally, I think the better approach for the libstdc++ parts is to allow __attribute__ visibility on namespace declarations. That way, all this goo could be removed, and centralized in one place. Ie, c++config.h could have something like: namespace std __attribute__ ((visibility ("default") )); { } And volia! We are done. (When I first saw this, I thought that the solution being proposed was mass decoration of std:: names with some kind of pseudo-__declspec bullshit. Of course, that is a non-starter, so I'm glad to see the thinking has evolved a bit.) -benjamin -- What|Removed |Added CC||bkoz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-02-08 01:14 --- The testcase patch is at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00287.html To properly support -fvisibility-inlines-hidden, ASM_OUTPUT_EXTERNAL should be defined. We can collected undefined symbols with non-default visibility and generate the assmebly directives in TARGET_ASM_FILE_END. -- What|Removed |Added Component|c |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-02-03 00:33 --- It is not OK. determine_visibility in C++ is called after ALL visibility push(default)/pop are processed. It has else if (TREE_CODE (decl) == FUNCTION_DECL && DECL_DECLARED_INLINE_P (decl) && visibility_options.inlines_hidden) { DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN; DECL_VISIBILITY_SPECIFIED (decl) = 1; } Here is where the problem comes from. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-02-03 00:29 --- I see, but please compare to the link in Comment #15: Mark Mitchell added visibility push(default)/pop to libsupc++ sure that the pragma was ok :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-02-03 00:24 --- I think the C++ compiler simply ignores default_visibility. That may be why push(default)/pop doesn't work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-02-03 00:18 --- Thanks HJ, things are becoming more and more ""interesting""... :-/ Seriously, I think we should split the issues: separate PRs, one category -target- for the relocation, one -library- for the missing visibility push(default)/pop. Maybe even a third one, -c++-, for the issue that you are reporting now. Help welcome... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-02-02 23:59 --- I am not sure if visibility push(default)/pop works at all since handle_pragma_visibility, which sets `default_visibility' with visibility push(default)/pop, is called AFTER build_decl_stat is called which uses default_visibility to set visibility. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-02-02 17:17 --- I believe it is a real compiler bug. I will see what I can do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-02-02 16:25 --- In other terms, I understand this > BTW, R_X86_64_PC32 CAN NOT be used for global symbols since it is only 32bit > while the address space is 64bit. x86 doesn't have this issue. as meaning that the compiler should *not* emit R_X86_64_PC32 in the first place, irrespective od other "details" affecting the c++ library. Thus, a *compiler* bug, certainly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-02-02 16:16 --- > My linker patch is for PROTECTED function symbols. It tries to prevent > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 Ok, just checked the testcase in binutils/584. > BTW, R_X86_64_PC32 CAN NOT be used for global symbols since it is only 32bit > while the address space is 64bit. x86 doesn't have this issue. OK, noted. Now, why: 1- Adding visibility push(default)/pop to the library does *not* help on x86_64 for this (comment #11) testcase? 2- Why visibility push(default)/pop are necessary only on x86_64?!? Sorry, two naive questions, but really before delving in the technical details I want to be sure that overall things are consistent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From hjl at lucon dot org 2005-02-02 16:09 --- My linker patch is for PROTECTED function symbols. It tries to prevent http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 BTW, R_X86_64_PC32 CAN NOT be used for global symbols since it is only 32bit while the address space is 64bit. x86 doesn't have this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-02-02 16:01 --- Hummm: http://sources.redhat.com/ml/binutils/2005-01/msg00511.html -- What|Removed |Added CC||aj at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-02-02 13:51 --- By the way: if this is really a generic problem in libstdc++, why I cannot reproduce it on x86? There, I'm using mainline as of February, 1 + binutils 2.15.94.0.2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-01-31 18:57 --- Adding pragma visibility push(default)/pop to the basic_string.h header (or to the std_string.h header, for that matter) does *not* fix the issue for me. Is anyone able to confirm this or viceversa? (binutils 2.15.91.0.2 on x86_64) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-01-31 10:32 --- Ok, now I see the issue clearly: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00114.html In particular: "I did not attempt to fix all of the V3 headers; I'm only concerned with libsupc++ at the moment. However, similar changes should probably be made throughout V3. Otherwise, linkage will be wrong if people #include (say) with a non-default symbol visibility." Will fix this. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pcarlini at suse dot de 2005-01-29 20:52 --- Interesting ;) After so many months, it turns out we have to add push/pop to *all* the headers?!? Why nobody mentioned that before?!? Not a big deal, in case, but I'm somewhat suprised. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 16:26 --- (In reply to comment #12) > I am sorry, in my attempt to reduce the exmaple I introduced a bug in the > testcase. Yes and this is not a target related bug at all but a libstdc++ one. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|target |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 15:37 --- Note the orginal testcase is: #include int some_function( std::string const& do_something ) __attribute__ ((visibility("default"))); int some_function( std::string const& do_something ) { std::string another_string; return 0; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-29 15:32 --- (In reply to comment #9) > (In reply to comment #8) > > I am also refereing to this example: > > http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html > > Now there is a libstdc++ bug for not using pop/push of the visibility in the > headers which is not what > I orginally thought this bug was about. If you actually commented saying that this came from libstdc++ and then I would have commented saying that there needs some push/pop in the headers but instead you gave a simplified example which is not a gcc/linker bug but a programmers mistake. Confirmed, changing the summary to match the correct the sumbitter's mistake of not giving the full story. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|target |libstdc++ Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-01-29 15:32:29 date|| Summary|-fvisibility-inlines-hidden |libstdc++ headers should |fails with gcc's extern |have pop/push of the |template extension on amd64 |visibility around the ||declarations http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664