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 :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
