Bug 268931 – LibraryTargets not installed correctly in kdebase; kdevelop fails to build

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Manuel Nickschas 2009-05-07 12:14:11 UTC]

KDevelop-9999 doesn't build because of a linker error. The reason for this is that our splitting of kdebase causes not all library target to be exported by cmake. In particular, KDevelop needs ksysguard's libprocessui; but there are several more libraries in kdebase that aren't exported either (just grep for EXPORT in CMakeLists.txt)

Following I'll quote an IRC log where I explain what I've figured out so far; please note that I haven't investigated the issue in too much detail, so I might be wrong with everything :)

------------8<--------------------------------

<Sput> wired: let me explain again... the issue is that several kdebase packages write library exports using cmake's EXPORT thingy
<Sput> those are supposed to end up in $PREFIX/lib64/cmake/KDE4Workspace-$version/KDE4WorkspaceLibraryTargets.cmake
<wired> but they go in /usr ?
<Sput> but we split kdebase, and kde4-meta eclass prevents generation of those files for any package that is not libkworkspace
<wired> ah
<Sput> so we end up with a file that does only contain the exports of libkworkspace, but none of the others
<Sput> upstream is nice enough to include any file of the form KDE4WorkspaceLibraryTargets-*.cmake from that file, so all we need to do is have every kdebase package using EXPORT to create a file for itself
<Sput> for some reason we never noticed that issue, presumably no package used that facility before, but now kdevelop won't build
<Sput> it needs the exports from libprocessui which is part of ksysguard.
<wired> i see
--> Gusar (n=[e-mail]) has joined #gentoo-kde
<Sput> wired: I guess rather than preventing the packages from installing KDE4WorkspaceLibraryTargets.cmake in the eclass (which is for collision protection), we should be renaming the file to KDE4WorkspaceLibraryTargets-${PN}.cmake
<Sput> if I understood everything correctly, that would fix the issue
<Sput> though I'm not completely sure if the files have the right content then, or need more seding (in particular, if the libkworkspace stuff would be created for every file, which would cause problems).


Reproducible: Always

Steps to Reproduce:
1. Build kdevelop-9999 from kde-testing overlay

Actual Results:  
Build aborts with a linker error that is claiming a non-existing library, which is actually caused by KDE4WorkspaceLibraryTargets*.cmake not containing libprocessui

Expected Results:  
Library targets should be correctly exported for all kdebase packages. We should be installing an export file in $prefix/lib64/cmake/KDE4Workspace-4.x.y for every package that uses EXPORT to kdeworkspaceLibraryTargets in CMakeLists.txt - those should be automatically included by the base file installed by libkworkspace

[Comment 1 Tomáš Chvátal (RETIRED) 2009-05-07 12:18:29 UTC]

This is really big bug in eclass. Adjusting severity. Really i had no idea about this till now Sput, you should have been more annoying to me because this should be highest priority to fix for me instead of toying with bump_tool. :]

[Comment 2 Maciej Mrozowski 2009-05-12 21:50:02 UTC]

Tomas, please revert your eclass KDE4Workspace play in overlay - it's not the way.
To generate correct export file it's needed (and maybe even sufficient) to compile together all libs that are part of this export.
This would only possibly require additional KMEXTRA lines in libkworkspace - and src_install override to not install those libs.
I'll play with this.

[Comment 3 Tomáš Chvátal (RETIRED) 2009-05-13 08:01:17 UTC]

(In reply to comment #2)
> Tomas, please revert your eclass KDE4Workspace play in overlay - it's not the
> way.
Okay, i think mine code is working, only problem is that i cant clearly detect if i am using exports or not (thanks to KM*).
Reverted and enjoy your try :]

[Comment 4 Tomáš Chvátal (RETIRED) 2009-05-25 16:44:26 UTC]

Ok we decided to not use it and hack around where we meet it.
Our kmsavelibs and kmloadlibs are much more flexible so we will try to enforce them everywhere.

[Comment 5 Maciej Mrozowski 2009-06-04 16:15:15 UTC]

Marked as resolved as we're not going to follow upstream here and we continue to workaround issue by not using library exports (replacing them with cmake target names).