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