[libvirt] [PATCH 2/2] Revert "Prevent more compiler optimization of mockable functions"

[Martin Kletzander]

On Wed, Jul 12, 2017 at 11:14:16AM +0100, Daniel P. Berrange wrote:
>This reverts commit e4b980c853d2114b25fa805a84ea288384416221.
>
>When a binary links against a .a archive (as opposed to a shared library),
>any symbols which are marked as 'weak' get silently dropped. As a result
>when the binary later runs, those 'weak' functions have an address of
>0x0 and thus crash when run.
>
>This happened with virtlogd and virtlockd because they don't link to
>libvirt.so, but instead just libvirt_util.a and libvirt_rpc.a. The
>virRandomBits symbols was weak and so left out of the virtlogd &
>virtlockd binaries, despite being required by virHashTable functions.
>
>Various other binaries like libvirt_lxc, libvirt_iohelper, etc also
>link directly to .a files instead of libvirt.so, so are potentially
>at risk of dropping symbols leading to a later runtime crash.
>
>This is normal linker behaviour because a weak symbol is not treated
>as undefined, so nothing forces it to be pulled in from the .a You
>have to force the linker to pull in weak symbols using -u$SYMNAME
>which is not a practical approach.
>

How is this done by gnulib (or libc) when most their functions are weak
aliases anyway?  Can't we use the same approach they have?
virtlo{g,ck}d link with libgnu.la as well and there is no problem with
that, right?  So I guess this _must_ be solvable somehow, IMHO.

I'm just curious how that works.

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170712/aed487e9/attachment-0001.sig>