| Summary: | kde-apps/kdepim-runtime-19.04.3 with parallel build gives fatal error: ui_lockfilepage.h: No such file or directory | ||
|---|---|---|---|
| Product: | [Applications] kdepim | Reporter: | piotr5 |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | asturm |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/kdepim-runtime/8ec4db907c403b24685a961b48be5f8a288d9bd9 | Version Fixed In: | 19.08.2 |
| Sentry Crash Report: | |||
| Attachments: |
New attempt
Next try |
||
You probably need https://cgit.kde.org/kdepim-runtime.git/commit/?id=062f5103 Please patch your kdepim-runtime package with this change and report back if it doesn't help. Git commit 4585292dd34f894505f8fc19e2bf51263768d688 by Christophe Giboudeaux. Committed on 09/08/2019 at 10:54. Pushed by cgiboudeaux into branch 'Applications/19.08'. Fix another race condition found while packaging the 19.08.0 release FIXED-IN: 19.08.0 CCMAIL: cfeck@kde.org M +1 -0 resources/mbox/CMakeLists.txt https://commits.kde.org/kdepim-runtime/4585292dd34f894505f8fc19e2bf51263768d688 (In reply to Christophe Giboudeaux from comment #1) > You probably need https://cgit.kde.org/kdepim-runtime.git/commit/?id=062f5103 This was already part of 19.04.3 release. Unfortunately, the new commit 4585292d does not seem to be enough either: https://bugs.gentoo.org/691938 In file included from /var/tmp/portage/kde-apps/kdepim-runtime-19.04.3/work/kdepim-runtime-19.04.3/resources/mbox/mboxresource.cpp:35: /var/tmp/portage/kde-apps/kdepim-runtime-19.04.3/work/kdepim-runtime-19.04.3/resources/mbox/compactpage.h:25:10: fatal error: ui_compactpage.h: No such file or directory #include "ui_compactpage.h" ^~~~~~~~~~~~~~~~~~ compilation terminated. I can't reproduce with various combinaisons of compilers and ninja flags, neither can build.kde.org (the issue was originally found on the BSD ci). I'm equally at a loss, but at this point there are definitely several downstream users with this problem. That seems limited to gentoo users though.The reason is still unknown. what is gentoo_common_config.cmake ? same for gentoo_toolchain.cmake What does -DCMAKE_BUILD_TYPE=Gentoo do exactly? is it reproducible if optional dependencies are not disabled (ie: no -DCMAKE_DISABLE_FIND_PACKAGE_Libkolabxml=ON) I'd also be interested in build results without the gentoo compiler/linker flags (In reply to Christophe Giboudeaux from comment #6) > what is gentoo_common_config.cmake ? This enforces global cmake projects packaging settings (copy from my own system): > SET (CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate Gentoo package build") > SET (LIB_SUFFIX 64 CACHE STRING "library path suffix" FORCE) > SET (CMAKE_INSTALL_LIBDIR lib64 CACHE PATH "Output directory for libraries") > SET (CMAKE_INSTALL_INFODIR "/usr/share/info" CACHE PATH "") > SET (CMAKE_INSTALL_MANDIR "/usr/share/man" CACHE PATH "") > SET (CMAKE_USER_MAKE_RULES_OVERRIDE "/var/tmp/portage/kde-apps/kdepim-runtime-19.08.1/work/kdepim-runtime-19.08.1_build/gentoo_rules.cmake" CACHE FILEPATH "Gentoo override rules") > SET (CMAKE_INSTALL_DOCDIR "/usr/share/doc/kdepim-runtime-19.08.1" CACHE PATH "") > SET (BUILD_SHARED_LIBS ON CACHE BOOLEAN "") (In reply to Christophe Giboudeaux from comment #6) > same for gentoo_toolchain.cmake Also from packaging for cmake projects (copy from my own system): > SET (CMAKE_ASM_COMPILER "x86_64-pc-linux-gnu-gcc") > SET (CMAKE_ASM-ATT_COMPILER "x86_64-pc-linux-gnu-gcc") > SET (CMAKE_C_COMPILER "x86_64-pc-linux-gnu-gcc") > SET (CMAKE_CXX_COMPILER "x86_64-pc-linux-gnu-g++") > SET (CMAKE_Fortran_COMPILER "x86_64-pc-linux-gnu-gfortran") > SET (CMAKE_AR /usr/bin/x86_64-pc-linux-gnu-ar CACHE FILEPATH "Archive manager" FORCE) > SET (CMAKE_RANLIB /usr/bin/x86_64-pc-linux-gnu-ranlib CACHE FILEPATH "Archive index generator" FORCE) > SET (CMAKE_SYSTEM_PROCESSOR "x86_64") (In reply to Christophe Giboudeaux from comment #6) > What does -DCMAKE_BUILD_TYPE=Gentoo do exactly? It is to enforce global compiler flags on all packages. There is a summary of the Gentoo configuration in build.log at the end of configure by example of the downstream report, nothing strikes me as out of the ordinary there, it is reflective of the user's CFLAGS/CXXFLAGS settings shown in the first (downstream) comment. copied from downstream user's build.log: > -- <<< Gentoo configuration >>> > Build type Gentoo > Install path /usr > Compiler flags: > C -O2 -march=native -pipe -fomit-frame-pointer -std=iso9899:1990 -fno-common -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wmissing-format-attribute -Wwrite-strings -Werror=implicit-function-declaration > C++ -O2 -march=native -pipe -fomit-frame-pointer -std=c++0x -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -Wsuggest-override -Wlogical-op -fdiagnostics-color=always -pedantic -Wzero-as-null-pointer-constant > Linker flags: > Executable -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed > Module -Wl,--no-undefined -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed > Shared -Wl,--no-undefined -Wl,--enable-new-dtags -Wl,-O1 -Wl,--as-needed (In reply to Christophe Giboudeaux from comment #6) > is it reproducible if optional dependencies are not disabled (ie: no > -DCMAKE_DISABLE_FIND_PACKAGE_Libkolabxml=ON) This is the only optional dependency here and in Gentoo indeed non-optional; libkolabxml package was removed from the official repo years ago. Created attachment 122976 [details]
New attempt
Let's try again. Please check if this patch helps
Created attachment 122977 [details]
Next try
Let's also tell CMake where these files come from.
New patch to test
Git commit 8ec4db907c403b24685a961b48be5f8a288d9bd9 by Christophe Giboudeaux. Committed on 03/10/2019 at 08:16. Pushed by cgiboudeaux into branch 'Applications/19.08'. Fix the dependencies on generated files differently. Some Gentoo users were still having build issues with the mbox resource. FIXED-IN: 19.08.1 M +13 -4 resources/mbox/CMakeLists.txt https://commits.kde.org/kdepim-runtime/8ec4db907c403b24685a961b48be5f8a288d9bd9 |
SUMMARY the gentoo package kde-apps/kdepim-runtime-19.04.3:5 aborts compilation because of above error, had no such problem in previous versions. maybe a problem of compilation-order? STEPS TO REPRODUCE 1. MAKEOPTS="-j6 -l6" emerge =kde-apps/kdepim-runtime-19.04.3 OBSERVED RESULT build.log contains nothing about ui_lockfilepage.h getting built and instead I get at the end: ... [370/746]... -c [...]/work/kdepim-runtime-19.04.3/resources/mbox/mboxresource.cpp FAILED: resources/mbox/CMakeFiles/akonadi_mbox_resource.dir/mboxresource.cpp.o In file included from [...]/work/kdepim-runtime-19.04.3/resources/mbox/mboxresource.cpp:37: [...]/work/kdepim-runtime-19.04.3/resources/mbox/lockmethodpage.h:25:10: fatal error: ui_lockfilepage.h: No such file or directory #include "ui_lockfilepage.h" ^~~~~~~~~~~~~~~~~~~ compilation terminated. [371/746]... -c resources/mixedmaildir/mixedmaildir_debug.cpp [372/746]... -c resources/mixedmaildir/mixedmaildirresource_debug.cpp [373/746]... -c resources/mixedmaildir/settings.cpp [374/746]... -c [...]/work/kdepim-runtime-19.04.3/resources/mixedmaildir/kmindexreader/kmindexreader.cpp [375/746]... -c resources/mbox/akonadi_mbox_resource_autogen/mocs_compilation.cpp ninja: build stopped: subcommand failed. EXPECTED RESULT correct multithreaded compilation just like from MAKEOPTS="-j1" emerge =kde-apps/kdepim-runtime-19.04.3 SOFTWARE/OS VERSIONS Linux/KDE Plasma: gentoo profile: default/linux/amd64/17.0/desktop/plasma/systemd (stable) kde-frameworks/plasma-5.60.0 is already compiled and installed ADDITIONAL INFORMATION haven't reported it in gentoo. seems in past bugs of that kind the solution was to forward-declare stuff instead of including the header-file which might not yet have been built in parallel-builds. doesn't ninja/cmake have any kind of dependency-tracking for that? or don't they cooperate in their dependency-tracking? maybe someone should file a bug in cmake and ninja?