--- 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 ch
--- 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
symbo
--- 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
--- 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: 17d812 OBJECT WEAK DEFAULT 20 vtable for foo
Then there is libl
--- 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
--
What|Removed |Added
CC||matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22063
--- 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
