[Bug c++/22063] New: link failure involving symbol visibility

[Bug c++/22063] New: link failure involving symbol visibility

[mueller at kde dot org]

I'm experiencing a build failure in a rather complex project which boils  
down to a class compiled with two different visibilities. it fails with this  
error, but only when using -fPIC  
 
linkfoo.o: In function `foo::foo()': 
linkfoo.cc:(.gnu.linkonce.t._ZN3fooC1Ev[foo::foo()]+0x11): undefined reference 
to `vtable for foo' 
/usr/lib/gcc/i586-suse-linux/4.0.1/../../../../i586-suse-linux/bin/ld: 
liblinkfoo.so: hidden symbol `vtable for foo' isn't defined 
/usr/lib/gcc/i586-suse-linux/4.0.1/../../../../i586-suse-linux/bin/ld: final 
link failed: Nonrepresentable section on output 
collect2: ld returned 1 exit status 
 
 
attaching testcase.

-- 
           Summary: link failure involving symbol visibility
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mueller at kde dot org
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i386-suse-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063

[Bug c++/22063] link failure involving symbol visibility

[mueller at kde dot org]

------- Additional Comments From mueller at kde dot org  2005-06-14 14:19 -------
Created an attachment (id=9088)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9088&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063

[Bug c++/22063] link failure involving symbol visibility

[matz at suse dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063

[Bug c++/22063] link failure involving symbol visibility

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-14 15:49 -------
I don't see anything wrong with the link error as you are saying that the class foo is only in liblinkfoo.so 
which is not true as the vtable is in libfoo.so.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063

[Bug c++/22063] link failure involving symbol visibility

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-06-14 16:13 -------
No. The vtable itself (as all methods of class foo) is implemented in 
libfoo.so with default visibility, i.e. exported just fine: 
    25: 000017d8    12 OBJECT  WEAK   DEFAULT   20 vtable for foo 
 
Then there is liblinkfoo, which just refers to the vtable.  It is compiled 
with the pragma visibility in effect in the declaration of class foo (i.e. 
simulating a header declaring a class of a library, where the pragma 
was in effect).  That lib is linked against the above libfoo.so. 
 
And this results in the mentioned link error.  The reference to the vtable 
from linkfoo.o also looks just fine: 
    14: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND vtable for foo 
i.e., UNDEF (and of course global, but that's irrelevant for a undef). 
 
This should not happen.  I could theorize, that this has something to do 
with the two definitions of the foo::foo ctor (in linkfoo.o it's hidden 
of course).  The "unresolvable" relocation is from that hidden implementation 
of foo::foo to the (global, exported in the other lib) vtable.  That 
implementation is also placed in a linkonce section, so that might be 
the reason too.  I changed the testcase a bit to implement the 
ctor out-of class, and removed the breakme method, i.e. it looks like so: 
------------------------------------- 
#pragma GCC visibility push( hidden ) 
class foo { 
public: 
   foo(); 
   virtual void bar(); 
}; 
foo::foo() {} 
------------------------------------- 
(this is linkfoo.cc)  together with the other virtualclass.cc this 
still reproduces the same error.  Here no linkonce sections are involved. 
The only thing is that the foo ctor is defined twice (but in different 
shared libs, so no problem), in the second lib hidden.  It still has a 
reference to the vtable defined in the first lib, which is exported. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063

[Bug c++/22063] link failure involving symbol visibility

[geoffk at gcc dot gnu dot org]

------- Comment #6 from geoffk at gcc dot gnu dot org  2006-04-19 19:23 -------
I believe that the problem here is that you haven't defined foo::bar in
linkfoo.so.  Because the foo in linkfoo.so is hidden, it is not the same foo as
the foo in liblinkfoo.so.


-- 

geoffk at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063

[Bug c++/22063] link failure involving symbol visibility

[matz at suse dot de]

------- Comment #5 from matz at suse dot de  2006-03-21 13:59 -------
There is no such thing as a hidden reference.  A symbol can be hidden,
then it's not exported and all references from inside DSO are directly bound
to it.  That's not the situation we have here.  We have a global exported
symbol ('vtable of foo') in libfoo.so, which somehow is not found by
the reference from inside liblinkfoo.so.  This might also be a linker error,
I don't know.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063

[Bug c++/22063] link failure involving symbol visibility

[jason at gcc dot gnu dot org]

------- Comment #4 from jason at gcc dot gnu dot org  2006-03-21 03:24 -------
I believe that 'hidden' references must bind to a definition in the current
.so, so this is not a bug.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063