[Bug gold/19842] LTO build fails to write call address for weak symbol reference

[dave.gittins at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=19842

gubbins <dave.gittins at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dave.gittins at gmail dot com

--- Comment #37 from gubbins <dave.gittins at gmail dot com> ---
I think I have encountered a different manifestation of this today.

I am building some code on x86_64 Linux with gcc 6.1.0 and ld. I have a
(non-LTO) static library which supplies the vtable for some class Foo. This is
present as a weak symbol in most of the object files in the library. Then I
build another project with LTO and try to link against the static library, and
the result is an undefined reference error for the vtable for Foo.

Building without lto works fine.

I have tried to follow some diagnosis steps as described here by re-running the
link stage with --save-temps -Wl,--no-demangle, and I can see (sorry names have
been changed for sensitivity reasons):

> grep _ZTVN13FooE *.s
MyBinary.ltrans10.s:     .hidden _ZTVN13FooE.lto_priv.7288
MyBinary.ltrans10.s:     .globl  _ZTVN13FooE.lto_priv.7288
MyBinary.ltrans10.s:     .type   _ZTVN13FooE.lto_priv.7288, @object
MyBinary.ltrans10.s:     .size   _ZTVN13FooE.lto_priv.7288, 40
MyBinary.ltrans10.s:_ZTVN13FooE.lto_priv.7288:

> grep _ZTVN13FooE lm.res
9895 8623386d5ae3a892 PREVAILING_DEF _ZTVN13FooE
461 30cecb5c4e192495 PREEMPTED_IR _ZTVN13FooE
403 efe4fb4175b858fe PREEMPTED_IR _ZTVN13FooE
1625 ae9effb0b2e1cafd PREEMPTED_IR _ZTVN13FooE
194 791c8af5cafa7aaf PREEMPTED_IR _ZTVN13FooE
194 723912904e42245c PREEMPTED_IR _ZTVN13FooE
194 11595667bd6932dc PREEMPTED_IR _ZTVN13FooE
9490 a6c87b9f8134adf5 PREEMPTED_IR _ZTVN13FooE

I also have .o files, but they seem to contain no symbols.

Reading this thread I think the linker is ignoring the weak symbols for
_ZTVN13FooE in my static library after encountering the PREVAILING_DEF - is
that right? Am I even on the right track here?


Strangely, building with -fno-strict-aliasing also works, although I don't yet
understand why that makes a difference...

-- 
You are receiving this mail because:
You are on the CC list for the bug.