Bug 19664 - libstdc++ headers should have pop/push of the visibility around the declarations
Summary: libstdc++ headers should have pop/push of the visibility around the declarations
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.2.0
Assignee: Benjamin Kosnik
URL:
Keywords: patch, visibility
: 21382 22185 22482 22587 24272 26217 26846 28449 30900 31459 (view as bug list)
Depends on: 20218 21764 26612 26984 27000
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-28 06:44 UTC by Andreas Pokorny
Modified: 2007-05-28 17:47 UTC (History)
31 users (show)

See Also:
Host:
Target: x86_64-pc-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-07-19 02:56:24


Attachments
Old libstdc++ patch, probably correct besides copyrights (6.39 KB, patch)
2005-05-17 08:58 UTC, Paolo Carlini
Details | Diff
reworked patch_19664. it applies on gcc_4 branch now. (6.58 KB, patch)
2005-05-17 09:41 UTC, Pawel Sikora
Details | Diff
Very slightly improved mainline patch for libstdc++-v3 (6.45 KB, patch)
2005-05-20 10:11 UTC, Paolo Carlini
Details | Diff
hidden visibility for __gnu_internal (1.57 KB, patch)
2005-10-31 16:47 UTC, Benjamin Kosnik
Details | Diff
smime.p7s (1.63 KB, application/pkcs7-signature)
2005-11-01 04:30 UTC, Geoff Keating
Details
Updated version of the patch to apply on current SVN (5.20 KB, patch)
2005-11-03 09:38 UTC, bero
Details | Diff
viz patch part one (1.44 KB, patch)
2006-07-19 02:52 UTC, Benjamin Kosnik
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Pokorny 2005-01-28 06:44:57 UTC
Failing code:
template<typename CharT>
struct VisTest
{
  inline VisTest ();
};
template<typename CharT>
inline VisTest<CharT>::VisTest()
{}
extern template class VisTest<char>;  // It works if we drop that line
int some_function( int do_something ) __attribute__ ((visibility("default")));
int some_function( int do_something )
{
  VisTest<char> a;
  return 0;
}

g++ -fPIC -fvisibility=hidden -fvisibility-inlines-hidden lib.cpp -c
g++ -shared -fPIC  -fvisibility=hidden -fvisibility-inlines-hidden lib.o -o
liblib.so

/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
lib.o: relocation R_X86_64_PC32 against `VisTest<char>::VisTest()' can not be
used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.0/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status

This happens with nearly all cases in which libstdc++ headers are involved:
http://bugs.gentoo.org/show_bug.cgi?id=78720
http://groups.google.de/groups?q=relocation+R_X86_64_PC32+against+making+a+shared+object&hl=de&lr=&selm=ct12kj%242njo%241%40FreeBSD.csie.NCTU.edu.tw&rnum=2
Comment 1 Paolo Carlini 2005-01-28 09:56:34 UTC
Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug:

  http://bugs.gentoo.org/show_bug.cgi?id=79711

???
Comment 2 Heinrich Wendel 2005-01-28 13:02:37 UTC
It may be related to this change in binutils: 
 
http://sources.redhat.com/ml/libc-alpha/2004-12/msg00062.html 
 
Changes from binutils 2.15.91.0.1: 
2. Fix the x86_64 linker to prevent non-PIC code in shared library. 
Comment 3 Paolo Carlini 2005-01-28 13:13:42 UTC
I think HJ may be interested...
Comment 4 Simon Strandman 2005-01-28 13:35:24 UTC
>Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug:
>
>http://bugs.gentoo.org/show_bug.cgi?id=79711

Downgrading binutils from 2.15.92.0.2 to 2.15.90.0.1.1 fixed the compilation for
all KDE packages except kdepim. But kdepim failed with another probably not
related error.
Comment 5 H.J. Lu 2005-01-29 01:05:46 UTC
It is a compiler bug. VisTest<char>::VisTest() is never defined.
R_X86_64_PC32 relocation may not reach it at runtime when it is
called. The new linker catches this particular bug at linktime.
Comment 6 Andrew Pinski 2005-01-29 13:05:05 UTC
(In reply to comment #5)
> It is a compiler bug. VisTest<char>::VisTest() is never defined.
> R_X86_64_PC32 relocation may not reach it at runtime when it is
> called. The new linker catches this particular bug at linktime.

Actually this is not a gcc or a linker bug but a programmers.
Basically -fvisibility=hidden -fvisibility-inlines-hidden says all I repeat all functions (defined or not) as 
hidden.
Comment 7 Andreas Pokorny 2005-01-29 15:08:50 UTC
If it is a programmers bug, why does it happen only with amd64, but not with
ia32 or ia64?

>  Actually this is not a gcc or a linker bug but a programmers.
>  Basically -fvisibility=hidden -fvisibility-inlines-hidden says all I repeat
all functions (defined or not) 
>  as hidden.

This does not explain why gcc should fail to create the library. In my opinion
the programmer isnt the one to blame, he declared a strucutre, which should not
be exported to the library, and a function that should be exported. Within his
library he uses that structure, whats wrong about that? 
Comment 8 Andreas Pokorny 2005-01-29 15:26:05 UTC
I am also refereing to this example: 
http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html
Comment 9 Andrew Pinski 2005-01-29 15:28:47 UTC
(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.
Comment 10 Andrew Pinski 2005-01-29 15:32:28 UTC
(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.
Comment 11 Andrew Pinski 2005-01-29 15:37:13 UTC
Note the orginal testcase is:
#include <string> 
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;
}
Comment 12 Andreas Pokorny 2005-01-29 16:24:37 UTC
I am sorry, in my attempt to reduce the exmaple I introduced a bug in the testcase. 
Comment 13 Andrew Pinski 2005-01-29 16:26:07 UTC
(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.
Comment 14 Paolo Carlini 2005-01-29 20:52:29 UTC
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.
Comment 15 Paolo Carlini 2005-01-31 10:32:22 UTC
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) <iostream> with a non-default symbol visibility."

Will fix this.
Comment 16 Paolo Carlini 2005-01-31 18:57:47 UTC
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)
Comment 17 Paolo Carlini 2005-02-02 13:51:39 UTC
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.
Comment 18 Paolo Carlini 2005-02-02 16:01:22 UTC
Hummm:

  http://sources.redhat.com/ml/binutils/2005-01/msg00511.html

Comment 19 H.J. Lu 2005-02-02 16:09:12 UTC
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.
Comment 20 Paolo Carlini 2005-02-02 16:16:36 UTC
> 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.
Comment 21 Paolo Carlini 2005-02-02 16:25:37 UTC
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.
Comment 22 H.J. Lu 2005-02-02 17:17:54 UTC
I believe it is a real compiler bug. I will see what I can do.
Comment 23 H.J. Lu 2005-02-02 23:59:05 UTC
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.
Comment 24 Paolo Carlini 2005-02-03 00:18:26 UTC
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...
Comment 25 H.J. Lu 2005-02-03 00:24:07 UTC
I think the C++ compiler simply ignores default_visibility. That may be why
push(default)/pop doesn't work.
Comment 26 Paolo Carlini 2005-02-03 00:29:52 UTC
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 :-(
Comment 27 H.J. Lu 2005-02-03 00:33:30 UTC
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.
Comment 28 Giovanni Bajo 2005-02-06 13:11:40 UTC
So this is both a compiler bug and a v3 bug. HJL provided a patch for the C++ 
frontend here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html
Notice that the patch is incomplete because it is missing a testcase.
Comment 29 Paolo Carlini 2005-02-06 13:19:25 UTC
A testcase suitably distilled from #11 should do.

For the libstdc++ side of the problem, we are missing a testcase. Probably, it's
better opening a separate, complete libstdc++ PR: then fixing the latter will be
straightforward (just add push/pop everywhere, I have a draft ready).
Comment 30 Paolo Carlini 2005-02-06 13:22:14 UTC
But, on second thought, sorry, I think we have also a third problem, target
dependent, for R_X86_64_PC32 relocaltions wrongly emitted for global symbols
on x86_64.
Comment 31 Paolo Carlini 2005-02-06 13:24:42 UTC
Actually, the testcase in comment #11 is about the *third* issue, AFAICS.
Comment 32 H.J. Lu 2005-02-06 16:23:22 UTC
I don't think emitting R_X86_64_PC32 is a bug since
-fvisibility=hidden -fvisibility-inlines-hidden is
used and the undefined function can be defined in
another .o file. The real bug is gcc doesn't emit

     .hidden foo

when foo is marked hidden and undefined.


Comment 33 H.J. Lu 2005-02-08 01:14:05 UTC
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.
Comment 34 Benjamin Kosnik 2005-02-25 22:40:47 UTC
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



Comment 35 Giovanni Bajo 2005-02-26 23:45:52 UTC
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.
Comment 36 H.J. Lu 2005-02-27 03:54:31 UTC
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.
Comment 37 Michael Matz 2005-04-18 12:49:21 UTC
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. 
Comment 38 Michael Matz 2005-04-18 12:50:21 UTC
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. 
Comment 39 Paolo Carlini 2005-04-18 14:14:41 UTC
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...
Comment 40 H.J. Lu 2005-05-04 17:15:20 UTC
*** Bug 21382 has been marked as a duplicate of this bug. ***
Comment 41 Paolo Carlini 2005-05-17 08:58:20 UTC
Created attachment 8908 [details]
Old libstdc++ patch, probably correct besides copyrights
Comment 42 Pawel Sikora 2005-05-17 09:41:43 UTC
Created attachment 8909 [details]
reworked patch_19664. it applies on gcc_4 branch now.
Comment 43 Mark Mitchell 2005-05-17 17:38:15 UTC
Subject: Re:  libstdc++ headers should have pop/push
 of the visibility around the declarations

pluto at agmk dot net wrote:
> ------- Additional Comments From pluto at agmk dot net  2005-05-17 09:41 -------
> Created an attachment (id=8909)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8909&action=view)
> reworked patch_19664. it applies on gcc_4 branch now.

This patch looks sensible to me, but it should be approved by a V3 
maintainer.

Comment 44 Paolo Carlini 2005-05-17 19:05:58 UTC
> 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 ;)
Comment 45 Pawel Sikora 2005-05-17 21:39:27 UTC
(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. 
Comment 46 Mark Mitchell 2005-05-17 21:40:35 UTC
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.

Comment 47 CVS Commits 2005-05-17 21:47:18 UTC
Subject: Bug 19664

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	hjl@gcc.gnu.org	2005-05-17 21:47:13

Modified files:
	gcc/cp         : ChangeLog decl2.c 

Log message:
	2005-05-17  H.J. Lu  <hongjiu.lu@intel.com>
	
	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

Comment 48 H.J. Lu 2005-05-17 21:50:36 UTC
Mark, is

http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html

OK for mainline as well as 4.0?
Comment 49 Mark Mitchell 2005-05-17 21:58:35 UTC
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.

Comment 50 Paolo Carlini 2005-05-17 22:00:28 UTC
> 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.
Comment 51 Pawel Sikora 2005-05-18 15:42:37 UTC
(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 :) 
 
Comment 52 Paolo Carlini 2005-05-18 15:45:15 UTC
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.
Comment 53 Bernardo Innocenti 2005-05-19 10:00:57 UTC
(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?
Comment 54 Mark Mitchell 2005-05-19 19:21:17 UTC
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.

Comment 55 Heinrich Wendel 2005-05-20 08:35:36 UTC
no workaround, the flag was just disabled on the affected architectures 
Comment 56 Pawel Sikora 2005-05-20 08:58:58 UTC
(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. 
Comment 57 Pawel Sikora 2005-05-20 09:02:38 UTC
(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 :/ 
 
Comment 58 Paolo Carlini 2005-05-20 09:03:51 UTC
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).
Comment 59 Paolo Carlini 2005-05-20 10:11:29 UTC
Created attachment 8934 [details]
Very slightly improved mainline patch for libstdc++-v3

Includes for completeness two missing TR1 headers; adjusts a DejeGNU line
number
mismatch in the auto_ptr/assign_neg.cc test.
Comment 60 Mark Mitchell 2005-05-20 18:48:31 UTC
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?

Comment 61 Andreas Jaeger 2005-05-21 16:50:30 UTC
Subject: Re:  libstdc++ headers should have pop/push of the visibility around the declarations

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> 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
Comment 62 Pawel Sikora 2005-07-06 08:34:46 UTC
(In reply to comment #59) 
> Created an attachment (id=8934) 
> Very slightly improved mainline patch for libstdc++-v3 
 
gcc-4.1-20050701T1908UTC with patches:   
{ ada-fwrapv pr7776 pr20218 pr20297 push-pop-visibility pr21704   
  pr22051 pr22071 pr17640 pr22037 pr22037 pr19055 }   
   
binutils-2.16.91.0.1   
   
on ia32 bootstrap (with all langs) works fine.   
on amd64 libstdc++ fails:   
   
(...)   
-march=x86-64 -O2 -fvisibility-inlines-hidden -D_GNU_SOURCE    
-fno-implicit-templates -Wall -W    
 extra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once    
-ffunction-sections -fdata-sections -c c++locale.cc  -fPIC -DPIC    
-o .libs/c++locale.o    
/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/xgcc    
-shared-libgcc    
-B/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/    
-nostdinc++    
-L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src    
-L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src/.libs    
-B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/    
-isystem /usr/x86_64-pld-linux/include    
-isystem /usr/x86_64-pld-linux/sys-include    
-I/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/include/x86_64-pld-linux    
-I/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/include    
-I/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/libstdc++-v3/libsupc++    
-march=x86-64 -O2 -fvisibility-inlines-hidden -D_GNU_SOURCE    
-fno-implicit-templates -Wall -W    
 extra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once    
-ffunction-sections -fdata-sections -c c++locale.cc -o c++locale.o >/dev/null    
2>&1    
cp /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/libstdc++-v3/config/linker-map.gnu ./libstdc++-symbol.ver    
if test "x" != x; then \    
  sed -n '1,/DO NOT DELETE/p' libstdc++-symbol.ver > tmp.top; \    
  sed -n '/DO NOT DELETE/,$p' libstdc++-symbol.ver > tmp.bottom; \    
  cat tmp.top  tmp.bottom > libstdc++-symbol.ver; \    
  rm tmp.top tmp.bottom; \    
fi    
/bin/sh ../libtool --tag CXX    
--mode=link /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/xgcc    
-shared-libgcc    
-B/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/    
-nostdinc++    
-L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src    
-L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src/.libs    
-B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/    
-isystem /usr/x86_64-pld-linux/include    
-isystem /usr/x86_64-pld-linux/sys-include -Wl,-O1   -fno-implicit-templates    
-Wall -Wextra -Wwrite-strings    
-Wcast-qual  -fdiagnostics-show-location=once  -ffunction-sections    
-fdata-sections   -o libstdc++.la -rpath /usr/lib64/../lib64 -version-info    
6:6:0 -Wl,--version-script=libstdc++-symbol.ver -lm  bitmap_allocator.lo    
pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo    
ctype.lo debug.lo debug_l    
 ist.lo functexcept.lo globals_locale.lo globals_io.lo ios.lo ios_failure.lo    
ios_init.lo ios_locale.lo limits.lo list.lo locale.lo locale_init.lo    
locale_facets.lo localename.lo stdexcept.lo strstream.lo tree.lo    
allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo io-inst.lo    
istream-inst.lo istream.lo locale-inst.lo locale-misc-inst.lo misc-inst.lo    
ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo    
valarray-inst.lo wlocale-inst.lo wstring-inst.lo atomicity.lo    
codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo    
monetary_members.lo numeric_members.lo time_members.lo basic_file.lo    
c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm     
/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/xgcc    
-shared-libgcc    
-B/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/    
-nostdinc++    
-L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src    
-L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src/.libs    
-B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/    
-isystem /usr/x86_64-pld-linux/include    
-isystem /usr/x86_64-pld-linux/sys-include -shared    
-nostdlib /usr/lib64/gcc/x86_64-pld-linux/../../../lib64/crti.o /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/crtbeginS.o  .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_locale.o .libs/globals_io.o .libs/ios.o .libs/i    
 
os_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/io-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/locale-misc-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o    
-Wl,--whole-archive ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a    
-Wl,--no-whole-archive  
-L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-    
 linux/libstdc++-v3/src    
-L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src/.libs    
-lm ../libmath/.libs/libmath.a -lm ../libsupc++/.libs/libsupc++convenience.a    
-lm    
-L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc    
-L/usr/lib64/gcc/x86_64-pld-linux/../../../lib64 -L/lib/../lib64    
-L/usr/lib/../lib64 -lgcc_s -lc -lgcc_s -lm -lgcc_s -lc    
-lgcc_s   /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/crtendS.o /usr/lib64/gcc/x86_64-pld-linux/../../../lib64/crtn.o  
-Wl,-O1    
-Wl,--version-script=libstdc++-symbol.ver -Wl,-soname -Wl,libstdc++.so.6    
-o .libs/libstdc++.so.6.0.6    
/usr/bin/ld: .libs/string-inst.o: relocation R_X86_64_PC32 against    
`_ZNSt11char_traitsIcE2eqERKcS2_@@GLIBCXX_3.4.5' can not be used when making a    
shared object; recompile with -fPIC    
/usr/bin/ld: final link failed: Bad value    
collect2: ld returned 1 exit status    
make[4]: *** [libstdc++.la] Error 1  
  
should i update the mainline patch?  
 
Comment 63 Paolo Carlini 2005-07-06 10:40:18 UTC
> 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... 
Comment 64 Andrew Pinski 2005-07-14 16:59:09 UTC
*** Bug 22482 has been marked as a duplicate of this bug. ***
Comment 65 Andrew Pinski 2005-07-21 16:17:58 UTC
*** Bug 22587 has been marked as a duplicate of this bug. ***
Comment 66 H.J. Lu 2005-08-21 20:25:51 UTC
*** Bug 22185 has been marked as a duplicate of this bug. ***
Comment 67 Andrew Pinski 2005-08-29 20:57:34 UTC
*** Bug 23628 has been marked as a duplicate of this bug. ***
Comment 68 Geoff Keating 2005-08-29 22:21:34 UTC
There was a comment in here about making visibility control happen at the namespace level.

How would this work with, say, 'vector<mytype>'?  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.
Comment 69 Andrew Pinski 2005-10-08 13:42:00 UTC
*** Bug 24272 has been marked as a duplicate of this bug. ***
Comment 70 Dirk Mueller 2005-10-21 11:36:09 UTC
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. 

Comment 71 Paolo Carlini 2005-10-21 11:40:27 UTC
(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.
Comment 72 Dirk Mueller 2005-10-24 05:22:11 UTC
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)

Comment 73 Paolo Carlini 2005-10-24 09:14:34 UTC
(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.
Comment 74 Dirk Mueller 2005-10-25 15:41:27 UTC
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. 
Comment 75 Paolo Carlini 2005-10-25 15:44:33 UTC
(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.

Comment 76 Benjamin Kosnik 2005-10-31 16:47:48 UTC
Created attachment 10085 [details]
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++.
Comment 77 Paolo Carlini 2005-10-31 16:59:57 UTC
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...
Comment 78 İsmail Dönmez 2005-10-31 18:37:18 UTC
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.
Comment 79 Geoff Keating 2005-10-31 22:14:03 UTC
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?


Comment 80 Dirk Mueller 2005-10-31 22:45:27 UTC
- 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". 

Comment 81 Geoff Keating 2005-10-31 23:29:04 UTC
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<mytype>', 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<mytype> 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<mytype> has  
to be hidden, but ctype<char> 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++.)

Comment 82 Paolo Carlini 2005-11-01 02:21:23 UTC
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.
Comment 83 Benjamin Kosnik 2005-11-01 03:59:23 UTC
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.
Comment 84 Geoff Keating 2005-11-01 04:30:59 UTC
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<int>", 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 Geoff Keating 2005-11-01 04:30:59 UTC
Created attachment 10094 [details]
smime.p7s
Comment 86 bero 2005-11-03 09:38:48 UTC
Created attachment 10120 [details]
Updated version of the patch to apply on current SVN
Comment 87 Pawel Sikora 2005-12-06 17:05:17 UTC
current 4.1(+libstdc++ patch) works fine for PR21382 on amd64 and ppc.
Comment 88 Geoff Keating 2005-12-15 23:41:55 UTC
This patch doesn't solve the vector<mytype> issue, does it?  It doesn't look like it, I would have expected it to need some C++ frontend changes.
Comment 89 Andrew Pinski 2006-02-11 17:14:45 UTC
*** Bug 26217 has been marked as a duplicate of this bug. ***
Comment 90 Pawel Sikora 2006-03-13 20:17:52 UTC
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.
0x00002aaaaaf641d8 in __gnu_cxx::__mt_alloc<Arts::Notification*, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate () from /usr/lib64/libartsflow.so.1
(gdb) bt
#0  0x00002aaaaaf641d8 in __gnu_cxx::__mt_alloc<Arts::Notification*, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate ()
    from /usr/lib64/libartsflow.so.1
#1  0x00002aaaaba4a908 in std::_Deque_base<Arts::Notification, std::allocator<Arts::Notification> >::_M_initialize_map ()
    from /usr/lib64/libmcop.so.1
#2  0x00002aaaaba49145 in Arts::NotificationManager::NotificationManager ()
    from /usr/lib64/libmcop.so.1
#3  0x00002aaaaba2660a in Arts::Dispatcher::Dispatcher ()
    from /usr/lib64/libmcop.so.1
#4  0x000000000041c227 in main (argc=1, argv=0x7fffffe818f8) 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)
Comment 91 Dirk Mueller 2006-03-14 09:24:18 UTC
well, of course, because your libstdc++ is compiled with the wrong (LSB incompliant btw) stdc++ allocator. 
Comment 92 Andrew Pinski 2006-04-03 23:57:47 UTC
Both PR 27000 and bug 26984 are reasons why push/pop will fail currently.
Comment 93 Geoff Keating 2006-04-04 00:23:52 UTC
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.

Comment 94 Andrew Pinski 2006-04-26 02:13:58 UTC
*** Bug 26846 has been marked as a duplicate of this bug. ***
Comment 95 Jakub Jelinek 2006-07-15 10:34:54 UTC
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.
Comment 96 Benjamin Kosnik 2006-07-19 02:52:10 UTC
Created attachment 11912 [details]
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)
Comment 97 Benjamin Kosnik 2006-07-19 02:56:24 UTC
Mine.
Comment 98 Andrew Pinski 2006-07-20 22:01:49 UTC
*** Bug 28449 has been marked as a duplicate of this bug. ***
Comment 99 Benjamin Kosnik 2006-07-20 23:37:37 UTC
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  <bkoz@redhat.com>
	    Jakub Jelinek  <jakub@redhat.com>
	
	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

Comment 100 Benjamin Kosnik 2006-07-28 04:57:43 UTC
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  <bkoz@wells.artheist.org>

	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

Comment 101 Benjamin Kosnik 2006-08-22 12:44:04 UTC
Fixed.
Comment 102 Andrew Pinski 2007-02-22 23:58:40 UTC
*** Bug 30900 has been marked as a duplicate of this bug. ***
Comment 103 Andrew Pinski 2007-04-03 17:37:00 UTC
*** Bug 31459 has been marked as a duplicate of this bug. ***
Comment 104 devsk 2007-05-28 04:15:55 UTC
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/lib64    libkhtml_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
----------------------------------------------------- 
Comment 105 Pawel Sikora 2007-05-28 05:01:24 UTC
(In reply to comment #104)
> kdelibs doesn't link with gcc-4.2.0 with hidden visibility.

you need a path for pr20218.
Comment 106 devsk 2007-05-28 05:16:01 UTC
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?
Comment 107 Simon Strandman 2007-05-28 11:49:07 UTC
(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
Comment 108 devsk 2007-05-28 17:47:27 UTC
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?