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)

This seems like a very invasive change.  I maintain a few projects
where undefined symbols in DSOs are a necessary and expected thing,
and I don't think I should need to set a flag to get them to compile.

In the bug the only justification for this change is:

  "This is very desirable for the Sun RPC removal, otherwise programs
  continue to build by accident."

Can you explain why programs will continue to build now that glibc has
removed xdr_* etc symbols?  In all the programs I have tried to build
which used SunRPC, none of them continued to build.  All required
explicit changes (eg. changing configure to detect libtirpc, adding
new linker flags).

> ### 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.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to