Description of problem:
libidn.pc says libidn.so is in /usr/lib(64) when it is actually in /lib(64)
(see bug 283651). The -devel symlink could be in /usr/lib(64) just fine
without breaking apps in /bin. Alternatively, the .pc file ought to be fixed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try building kdenetwork against libidn.
/builddir/build/BUILD/kdenetwork-4.0.3/kopete/protocols: Disabled Jabber
because libidn-devel was not found (bug 439465).
I'm adding a quick workaround to kdenetwork for now, but this should be fixed
ASAP as it's likely to also affect other packages.
My first analysis was incorrect: the problem is the opposite of how I described
it: the symlink is already in /usr/lib(64), however pkgconfig has its libdir
set to /lib(64). cmake uses that libdir as the place to find the -devel symlink
in. This probably won't affect packages using something else
because /usr/lib(64) is in the default linker search path, however cmake wants
to find the actual file using its own search algorithm, and kdenetwork's
FindIDN.cmake explicitly disables the fallback paths.
FYI, I applied this patch to kdenetwork for now:
Fixed in libidn-0.6.14-7.