On 01/23/2018 12:26 PM, Mamoru TASAKA wrote:
Florian Weimer wrote on 01/23/2018 12:24 AM:
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.
So this seems to affect lots of packages containing
/usr/lib64/foo/libbar.so. At least my packages
- cairo-dock
It's not clear whether this isn't rather a package bug. Many symbols
could come from -lgldi as well, but some of them are defined by
/usr/bin/cairo-dock as well. However, that program has a DT_NEEDED
entry for libgldi.so.3, so it is unclear what is going on.
Have you tried adding the missing -l arguments?
- cairo-dock-plug-ins
(not checked)
- gnome-commander
This has a plugin-style reference for main_win_widget (which is only
defined in /usr/libexec/gnome-commander/gnome-commander), but failures
further down are to a missing -lgcmd. Definitely a mixed bag.
failed to build due to this, and at least
- dia
Looks like a missing -lglib-2.0, so it's a package bug.
- sssd
Looks like a package bug, probably a missing -lsss_util. (Although it
is not entirely clear which sssd shared object contains the canonical
definition of each function.)
- ModemManager
This is a true plug-in case, so it needs to avoid to build with -z defs
(which will obscure the missing -lglib-2.0, which should nevertheless be
added).
- pidgin
Looks like a missing -lpurple -lpthread -lglib-2.0, probably more.
(/usr/sbin/bitlbee defines some purple_* symbols, but I don't know if
any of the compiled DSOs are in fact plug-ins for that program. If not,
it should be possible to get the whole thing to link with -z defs.)
So the majority of these issues are package bugs. This is not entirely
what I expected—in an ideal world, the impact would have been restricted
to true plug-ins. Some of the existing linking issues aren't entirely
harmless and can cause problems today or further down the road (because
the dependency information on various layers is incorrect).
We could deactivate -z defs for F28 and reactivate it after the branch
for F29, giving packagers more time to fix issues.
Thanks,
Florian
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
