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.
Created attachment 9088 [details] testcase
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.
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.
I believe that 'hidden' references must bind to a definition in the current .so, so this is not a bug.
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.
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.