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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
