This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire
- From: "mstahl at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 04 Dec 2015 12:18:30 +0000
- Subject: [Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire
- Auto-submitted: auto-generated
- References: <bug-64812-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812
--- Comment #14 from Michael Stahl <mstahl at redhat dot com> ---
(In reply to Jan Hubicka from comment #12)
> the devirtualization seems valid to me. You are supposed to link with the
> implementaiton of the class. It is possible to overwrite this by manually
> setting the visibility.
actual code in LibreOffice *did* link with the implementation of the class -
there were 2 libraries involved, "toolkit" contained the implementation of
ListenerMultiplexerBase and "svxcore" linked against it;
ListenerMultiplexerBase has __attribute__ ((visibility("default"))) so its
member functions should be exported.
the member functions in question (acquire and release) are inline, and i was
assuming that it's ok then that they are not exported from the library
containing the impl. of the class, but if you say that linking needs to happen
anyway then maybe the bug is that the inline functions are not exported from
the "toolkit" library by GCC.