On Tue, Jan 23, 2018 at 02:04:26PM +0100, Florian Weimer wrote:
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?
The stuff the modules depend on is probably all in libvirt.so, but
I'm not 100% that's the case for all our modules - the build failure
above stopped the build before getting onto many of our other modules.
I'll have a go at explicitly linking the plugins with libvirt.so upstream
though, to see if that's sufficient to kee the linker happy, and if so
add '-z defs' by default to upstream's build.
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 don't think we do symbol interposition
> 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.
Ok, thanks.
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|