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. 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 ? We could potentially explore a change to our build system upstream so add "-z defs" only to libvirt.so (which uses the xdr_* APIs) but *not* the loadable modules. IIUC, that would protect us for the symbol resolution without triggered the undefined symbols problem in other parts of our code. 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
