On 01/23/2018 01:49 PM, Daniel P. Berrange wrote:
On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:
> I updated redhat-rpm-config to instruct ld to reject linking shared objects
> with undefined symbols. Such undefined symbols break symbol versioning
> because the are not necessarily bound to the correct symbol version at run
> time. (rhbz#1535422)
>
> ### Disable strict symbol checks in the link editor (ld)
>
> By default, the link editor will refuse to link shared objects which
> contain undefined symbols. In some cases (such as when a DSO is
> loaded as a plugin and is expected to bind to symbols in the main
> executable), undefined symbols are expected. In this case, you can
> add
>
> %undefine _strict_symbol_defs_build
>
> to the RPM spec file to disable these strict checks. Alternatively,
> you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
> command line). The latter needs binutils 2.29.1-12.fc28 or later.
This affects libvirt, because we have a tonne of dlopen()able modules
which have undefined symbols that get resolved against the binary
that's loading them:
https://kojipkgs.fedoraproject.org//work/tasks/4413/24394413/build.log
I'll add the "%undefine _strict_symbol_defs_build" stanza to the RPM
spec for now.
Some of these symbols are also defined in libvirt.so.0. In fact, in the
link failure above, I don't see a *single* symbol which isn't defined in
libvirt.so.0. And /usr/sbin/libvirtd has a DT_NEEDED entry for
libvirt.so.0 anyway, so it's not actually about loading libvirt.so.0.
This looks more like the new style of doing plug-ins, where the shared
code is in a separate DSO which is linked from both the main application
and the plug-ins. In this case, maybe you can complete the transition
and avoid quite a bit of duplicate by removing the definitions from the
main program?
If there is deliberate symbol interposition going on to alter the
functionality of libvirt.so.0, then this will continue to work even if
the plug-ins are linked explicitly against libvirt.so.0.
I wonder if you can elaborate on what we should look out for wrt the
glibc vs tirpc symbol resolution problem mentioned. libvirt uses
XDR APIs, so is potentially affected by this. In rawhide, we are
linking with an explicit "-ltirpc" line already though. Is that
enough to avoid the problems you describe wrt xdr_* symbols getting
incorrectly resolved ?
The xdr_* symbols should have TIRPC_* symbol version. Then you are good.
Thanks,
Florian