|Summary:||Please fix libidn.pc file|
|Product:||[Fedora] Fedora||Reporter:||Kevin Kofler <kevin>|
|Component:||libidn||Assignee:||Joe Orton <jorton>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-03-31 10:25:38 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Kevin Kofler 2008-03-29 03:10:13 UTC
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.
Comment 1 Kevin Kofler 2008-03-29 03:30:21 UTC
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.
Comment 2 Kevin Kofler 2008-03-29 03:51:06 UTC
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
Comment 3 Joe Orton 2008-03-31 10:25:38 UTC
Fixed in libidn-0.6.14-7.