Yes that's one workaround we discussed, but not a good one for me as
it is difficult for me to modify that library.
But I would like to understand if this really is a gcc bug, rather
than just find a workaround and move on.
On Wed, Jun 15, 2016 at 10:39 PM, lh mouse <lh_mouse@xxxxxxx> wrote:
> Would you please try moving the definition of the virtual destructor out of the header (into some cpp file). This is practically a bad idea as it bloats each object file that uses the header with RTTI and can lead to unexpected results when using dynamic_cast or exceptions.
>
> ------------------
> Best regards,
> lh_mouse
> 2016-06-15
>
> -------------------------------------------------------------
> 发件人：Dave Gittins <dave.gittins@xxxxxxxxx>
> 发送日期：2016-06-15 20:29
> 收件人：gcc-help@xxxxxxxxxxx
> 抄送：
> 主题：Bogus unresolved references to vtable when building with lto
>
> Hi,
>
> I have a program that unexpectedly hit a linker error when building on
> x86_64 Linux with ld / gcc 6 and using LTO.
>
> Sorry but I have not managed to extract a sensible test case so far
> due to the large size (and sensitivity) of the code base. I am still
> trying to chop it down without losing the result. Meanwhile I'll
> describe the setup and hope someone can help me.
>
> * the main program builds with LTO and aggressive optimisation
> * it links against a library libfoo, built elsewhere with gcc but without LTO
> * foo.h contains:
> class Foo { virtual ~Foo() {}; virtual blah() = 0; };
> * libfoo.a contains the vtable for Foo in multiple object files
> (using comdat groups)
> * classes that inherit from Foo are used in the program
>
> Result:
> 1. with gcc 5.2 using -flto -O3: OK
> 2. with gcc 6.1 using -O3 (no LTO): OK
> 3. with gcc 6.1 using -flto -O3 -fno-strict-aliasing: OK
> 4. with gcc 6.1 using -flto -O3: linker error: unresolved reference
> to vtable for Foo
>
>
> I am not very familiar with the inner workings of LTO, but re-running
> the link step with --save-temps and looking at the output files, I can
> see one difference between cases 3 and 4: in case 3 the vtable symbol
> is present in a .s file for the target (e.g. _ZTVN3FooE seems to be
> defined) but in the failing case 4 it is called
> _ZTVN3FooE.lto_priv.7288. In both cases, the lm.res file contains
> something like this:
>
> lm.res:194 857f97bd35affadb PREVAILING_DEF _ZTVN3FooE
> lm.res:9895 38fe32bfc94fb92d PREEMPTED_IR _ZTVN3FooE
> lm.res:461 979b2bacd9a23781 PREEMPTED_IR _ZTVN3FooE
> lm.res:403 d7cb462ac76ae78f PREEMPTED_IR _ZTVN3FooE
> lm.res:1625 1c237136eccb8e22 PREEMPTED_IR _ZTVN3FooE
> lm.res:194 dc12ecd964eef823 PREEMPTED_IR _ZTVN3FooE
> lm.res:194 b0ceb27c32d02e6b PREEMPTED_IR _ZTVN3FooE
> lm.res:194 f7293254f09d2c44 PREEMPTED_IR _ZTVN3FooE
> lm.res:9490 fa5a2b6c2738a867 PREEMPTED_IR _ZTVN3FooE
>
> I also added this as a comment on this bug report but now I am not
> sure if it's really directly related:
> https://sourceware.org/bugzilla/show_bug.cgi?id=19842
>
> I think the LTO script is telling the linker that it will provide this
> symbol, and then providing it as a global symbol in the working case,
> but then in the failing case it is making it local, or something like
> that? I assume the optimiser came to some relevant conclusion about
> the required visibility of the vtable...?
>
> Any help appreciated.
>
> Dave
>
>
