When building Okteta in parallel, compile intermittently fails: Building CXX object okteta/gui/CMakeFiles/oktetagui.dir/controller/zoomwheelcontroller.o [0m/usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../x86_64-pc-linux-gnu/bin/ld: error: cannot find -lkasten2core The full build log is attached.
Hi Michael, thanks for your report. Never heard of such a problem, so curious how this could happen for you. Seems the full build log did not make it yet to this report, so could you please retry to attach it? The snippet you pasted above does not help, as this seems to be the mixed output of a build with parallel jobs, which sadly all output to the same place, adding lines to the output as they are created. I can see this because the first line is about compiling a source file to an object file, while the second line is the error output from the linker, which is a separate step and would have first a "Linking [something]" line before a possible error output. And just the second line does not tell what was going to be linked. Besides attaching the full log, could you please also try to do a build with no parallel jobs and tell if it also fails? And what sources are you using? From your distribution or pulled from the KDE repos? Which branch? Could you tell what "svn info" tells for URL: and Revision:?
Created attachment 73160 [details] build log Thanks for the response. Attached is the missing build log, and here is the SVN information you requested: URL: svn+ssh://palimaka@svn.kde.org/home/kde/trunk/KDE/kdesdk/okteta Revision: 1310636 Further, build without parallel jobs is always successful. Sorry for neglecting to include this information in the original report.
Thanks Michael. The full log is helpful and shows that linking of libkasten2okteta1core fails, because for some reason the buildsystem seems to miss the internal dependency to the lib kasten2core and to make sure it is build before. I have an idea where this could come from, but need to consult the KDE buildsystem experts for this :)
Created attachment 73425 [details] Possible patch, using the internal lib name, not the output lib name in the target link libraries list Michael, could you try if this patch solves the problem for you?
Hi, With that patch, parallel build succeeds for me ever time. Thanks!
Good, thanks for testing the patch, I am going to commit it to 4.9 and trunk next. BTW, to boost compiling of kdesdk or okteta, you could also use the cmake flag -DKDE4_ENABLE_FINAL=ON , that should work for 4.9 and trunk. (given you have enough working memory, no link at hand what would be needed) That flag results in all source files put in one file which then gets compiled, please ask google if you have more interest in that :)
SVN commit 1313158 by kossebau: Fixed: ensure dependencies between base Kasten libs and OktetaKasten libs (using targetnames, not output names) As long as the base Kasten libs are part of the build tree of Okteta, the linking lists need to use the the target names instead of the output names, otherwise the dependency is not known. M +4 -3 CMakeLists.txt WebSVN link: http://websvn.kde.org/?view=rev&revision=1313158
SVN commit 1313159 by kossebau: Fixed: ensure dependencies between base Kasten libs and OktetaKasten libs (using targetnames, not output names) (backport of 1313158) As long as the base Kasten libs are part of the build tree of Okteta, the linking lists need to use the the target names instead of the output names, otherwise the dependency is not known. M +4 -3 CMakeLists.txt WebSVN link: http://websvn.kde.org/?view=rev&revision=1313159