public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "matz at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/22063] link failure involving symbol visibility
Date: Tue, 14 Jun 2005 16:13:00 -0000	[thread overview]
Message-ID: <20050614161310.6503.qmail@sourceware.org> (raw)
In-Reply-To: <20050614141844.22063.mueller@kde.org>


------- 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


  parent reply	other threads:[~2005-06-14 16:13 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-14 14:18 [Bug c++/22063] New: " mueller at kde dot org
2005-06-14 14:19 ` [Bug c++/22063] " mueller at kde dot org
2005-06-14 15:03 ` matz at suse dot de
2005-06-14 15:49 ` pinskia at gcc dot gnu dot org
2005-06-14 16:13 ` matz at suse dot de [this message]
     [not found] <bug-22063-3563@http.gcc.gnu.org/bugzilla/>
2006-03-21  3:24 ` jason at gcc dot gnu dot org
2006-03-21 13:59 ` matz at suse dot de
2006-04-19 19:24 ` geoffk at gcc dot gnu dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050614161310.6503.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).