Description of problem: Clashes for /usr/lib/libX11.so.6.2.0: with /usr/lib/libFS.so.6.0.0 => in6addr_any with /usr/lib/libICE.so.6.3.0 => in6addr_any with /usr/lib/libXfont.so.1.4.1 => in6addr_any libX11-1.0.3-4.fc6.i386
Just for the record the other X ones are: Clashes for /usr/lib/libXfont.so.1.4.1: with /usr/lib/libXdmcp.so.6.0.0 => Xfree Xrealloc Xalloc ... with /usr/lib/libgs.so.8.15 => scan_token
Since this bugzilla report was filed, there have been several major updates, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their distribution available. Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Matej, nothing has changed here. All these symbols are still there, and still clash, e.g [mclasen@localhost ~]$ nm -D /usr/lib/libX11.so.6 | grep in6addr 00921c10 V in6addr_any [mclasen@localhost ~]$ nm -D /usr/lib/libICE.so.6 | grep in6addr 00d43214 V in6addr_any [mclasen@localhost ~]$ nm -D /usr/lib/libXfont.so | grep in6addr 00783378 V in6addr_any
Technically speaking that's not an error then. 'V' means weak object; a strong definition in glibc will override all the weak definitions, otherwise the value goes to zero with no error. The Xdmcp collision is gone as of a while ago. The scan_token one is harmless, since nothing links against both libXfont and libgs, but I built a fix for it anyway as libXfont-1.3.1-4.fc9.