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): libidn-0.6.14-6.fc9 How reproducible: Always Steps to Reproduce: 1. Try building kdenetwork against libidn. Actual results: /builddir/build/BUILD/kdenetwork-4.0.3/kopete/protocols: Disabled Jabber because libidn-devel was not found (bug 439465). Expected results: libidn found. Additional info: 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: http://cvs.fedoraproject.org/viewcvs/rpms/kdenetwork/devel/kdenetwork-4.0.3-libidn.patch?rev=1.2&view=markup
Fixed in libidn-0.6.14-7.