| Summary: | dev-build/cmake-3.14.6 FEATURES=distcc - The C++ compiler does not support C++11 (e.g. std::unique_ptr) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jan Vansteenkiste <jan> |
| Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | can.ecodo.nu.n.o+bugs.gentoo, eike, i.stakenvicius, kde, lssndrbarbieri, marcelo.ru, martin-kokos, matoro_gentoo, sam |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://gitlab.kitware.com/cmake/cmake/-/issues/22573 | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=836007 https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9574 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Regexp filter distcc warnings.
bug-691544_cmake-3.17.4.patch Bypass cmake bugous c++11 check |
||
|
Description
Jan Vansteenkiste
2019-08-06 07:23:15 UTC
I have a similar problem. I have distcc enabled, but there is currently no distccd server running, so it falls back to compiling locally. This produces a warning, which can be seen in /var/tmp/portage/dev-util/cmake-3.14.6/work/cmake-3.16.6_build/CMakeFiles/CMakeError.log. Here are the relevant lines from mine (with a lot of the arguments filtered out for clarity): Building CXX object CMakeFiles/... /usr/lib/distcc/bin/x86_64-pc-linux-gnu-g++ ... distcc[123] (dcc_build_somewhere) Warning: failed to distribute, running locally instead Linking CXX executable ... /usr/bin/cmake -E cmake_link_script ... /usr/lib/distcc/bin/x86_64-pc-linux-gnu-g++ ... The command actually completes successfully. However, in the cmake source directory, Source/Checks/cm_cxx_features.cmake checks for the word ``warning'' (case insensitive) in the output. It whitelists a few known warnings that should not cause a failure, and will fail the test for any other warning, even if the command completes successfully. The distcc warning above triggers this. This is why compiling without distcc succeeds (for me); without distcc, the warning line is not present. In my case, I should fix this by either disabling distcc, since I am not using it, or running distccd and using it, but I opted to simply add a regex whitelisting my warning to Source/Checks/cm_cxx_features.cmake. I recommend checking (or posting) your CMakeError.log file for the word ``warning''. When the compile fails, emerge should have printed a message giving the full path to CMakeError.log (should be similar to my path above). If there is a distcc warning given there, that is probably triggering the problem. I hit the bug in the way Anon Emuss described during an upgrade, but my usual distcc-server is currently down. I solved it by pointing distcc to a different server. This work around is pretty easy - but finding this information here was more or less good luck. The search in the forum did not retrieve useful information. I'm sorry - I meant the whole thread: https://forums.gentoo.org/viewtopic-p-8361378.html to me it fails even with either FEATURES="-distcc -ccache" Tried GCC 4, 6, 8, and all fail. cmake-3.14-6, cmake-3.16.2-r1 all fail same error. Doesn't seem to be a distcc issue -- The C compiler identification is GNU 6.4.0 -- The CXX compiler identification is GNU 6.4.0 -- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- Check for working C compiler: /usr/bin/x86_64-pc-linux-gnu-gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ -- Check for working CXX compiler: /usr/bin/x86_64-pc-linux-gnu-g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Detecting CXX compile features -- Detecting CXX compile features - done -- Checking if compiler supports C11 _Thread_local -- Checking if compiler supports C11 _Thread_local - yes -- Checking if compiler supports needed C++17 constructs -- Checking if compiler supports needed C++17 constructs - yes -- Checking if compiler supports C++ make_unique -- Checking if compiler supports C++ make_unique - no -- Checking if compiler supports C++ unique_ptr -- Checking if compiler supports C++ unique_ptr - no CMake Error at CMakeLists.txt:92 (message): The C++ compiler does not support C++11 (e.g. std::unique_ptr). (In reply to skaumo from comment #5) > to me it fails even with either FEATURES="-distcc -ccache" >... > same error. Doesn't seem to be a distcc issue Sounds like that might be a different issue, but you should be able to diagnose it the same way. Try checking your CMakeError.log file as described in comment #1 for any obvious warning or error messages. (In reply to skaumo from comment #5) > to me it fails even with either FEATURES="-distcc -ccache" > > Tried GCC 4, 6, 8, and all fail. > > cmake-3.14-6, cmake-3.16.2-r1 all fail > > same error. Doesn't seem to be a distcc issue > The C++ compiler does not support C++11 (e.g. std::unique_ptr). I had the same issue. After: env-update && source /etc/profile >>> Installing (1 of 1) dev-util/cmake-3.16.5::gentoo all looks good. :-) Created attachment 640592 [details, diff]
Regexp filter distcc warnings.
This is caused by
Source/Checks/cm_cxx_features.cmake
checking the output of the build, not the result code, of
Source/Checks/cm_cxx_unique_ptr.cxx
The check defines a couple of warnings that are filtered, and any warning will be treated as a catastrophic failure:
31 # If using the feature causes warnings, treat it as broken/unavailable.
32 if(check_output MATCHES "(^|[ :])[Ww][Aa][Rr][Nn][Ii][Nn][Gg]")
33 set(CMake_HAVE_CXX_${FEATURE} OFF CACHE INTERNAL "TRY_COMPILE" FORCE)
34 endif()
35 if(CMake_HAVE_CXX_${FEATURE})
36 message(STATUS "Checking if compiler supports C++ ${name} - yes")
37 file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeOutput.log
38 "Determining if compiler supports C++ ${name} passed with the following output:\n"
39 "${OUTPUT}\n"
40 "\n"
41 )
42 else()
43 message(STATUS "Checking if compiler supports C++ ${name} - no")
44 file(APPEND ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeError.log
45 "Determining if compiler supports C++ ${name} failed with the following output:\n"
46 "${OUTPUT}\n"
47 "\n"
48 )
49 endif()
This is terribly bad design in a critical codepath.
Either way, I have attached a patch to make distcc warnings disappear, but your cases of breakage may be different, so you may have to craft your own until upstream realises the error of their ways.
I've attached a patch for distcc, I'll also try to submit it upstream.
(In reply to Felix W. from comment #8) > I've attached a patch for distcc, I'll also try to submit it upstream. Thanks, did you follow up on that? Can we track an upstream link? The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=798815cd723550bb4b9141ded9e50c12a74ed3e2 commit 798815cd723550bb4b9141ded9e50c12a74ed3e2 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2020-07-22 16:26:02 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2020-07-22 16:26:46 +0000 dev-util/cmake: Bump to version 3.18.0. Removed old Filter out distcc warnings Thanks-to: Felix W. <felix.wischke@gmail.com> Bug: https://bugs.gentoo.org/691544 Package-Manager: Portage-3.0.0, Repoman-2.3.23 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> dev-util/cmake/Manifest | 2 +- .../{cmake-3.18.0_rc4.ebuild => cmake-3.18.0.ebuild} | 2 ++ .../files/cmake-3.18.0-filter_distcc_warning.patch | 17 +++++++++++++++++ 3 files changed, 20 insertions(+), 1 deletion(-) Getting this error with v.3.16.5 on armv7a-unknown-linux-gnueabihf. I was able to fix it using Felix's patch. Created attachment 670724 [details, diff]
bug-691544_cmake-3.17.4.patch
Same here. Getting this error with cmake-3.17.4-r1 (current stable) using distcc on armv7a-unknown-linux-gnueabihf.
Here's Felix's patch ported to this older version.
I'm hitting the same but I don't use distcc nor ccache but clang on musl > I've attached a patch for distcc, I'll also try to submit it upstream.
This has never happened, did it? Please open a MR at gitlab.kitware.com otherwise.
Created attachment 760181 [details, diff] Bypass cmake bugous c++11 check There were several more complains about this bug. I promptly found 1) a thread at stackoverflow where they blame cross build [ https://stackoverflow.com/questions/55772725/the-c-compiler-does-not-support-c11-e-g-stdunique-ptr-building-openwrt ], 2) a post in a blog where they blame mount directory and c flags [ https://thelinuxcluster.com/2021/10/01/the-c-compiler-does-not-support-c11-during-bootstrap-for-cmake/ ], 3) a gitlab thread where they blame distcc [ https://gitlab.kitware.com/cmake/cmake/-/issues/22573 ], 4) a discussion in the official CMake forum where they blame windows for it [ https://discourse.cmake.org/t/cmake-error-at-cmakelists-txt-117-message-the-c-compiler-does-not-support-c-11-e-g-std-unique-ptr/3774 ] and last but least a gentoo bug where they blame enviroment variables too [ https://bugs.gentoo.org/691544 ]. Each of them finds a different work around: moving the build to another directory, remounting a storage point, changing c flags to "-O3", switching windows subsystem for linux implementation, force usage of C++14, etc. I personally bypassed this check as I was sure my compiler supported C++11 features like 'std:unique_ptr' despite Cmake complains. It's not a definite patch, but as it's been a standard since late 2000's, very few people should not have C++11 support and those who don't must be very well aware of what they're doing. I just ran into this bug too. I am building on an nfs root. The build system and the server were a few dozen milliseconds off, and the warning was "clock skew detected". The nfs server is also the ntp server used by the build system, so the time is never off by much. Also confirming that this issue can be caused by even tiny amounts of clock skew when building on NFS root. having the same problem with distcc, from the first glance as google results I figured I would disable it, but it still persisted.
/var/tmp/ is on NFS share, topologically very close by (1 ProCurve switch, 5 meters CAT5e cable length total) ; to reduce timedelta I setup ntpd on nfs server (disabled rate limiting) and ran `while [ 1 ] ; do ntpdate server ; sleep 5 ; done`. This resulted in the following time offsets:
Dataset statistics:
Number of samples: 213
Mean: 0.00025464319248826294
Fast mean: 0.00025464319248826294
Geometric mean (abs): 0.0003048933118422922
Median (low, mid, high): 0.000319 0.000319 0.000319
50th percentile: 0.0003190000000000137
Modes (most common values): [0.000271]
Quantiles: [0.00017900000000000001, 0.000319, 0.0005005]
the test lasted a little less than 40 minutes.
Compilation proceeded with no problems, with distcc (no precaution was taken regarding clock skew on distcc nodes - 6 hosts total)
cheers
I should add that I did an intermediary test where both NFS server and compiling host (same distcc configuration) were both synchronising against an NTP server a tad further away (compiling host was the router for NFS host), with a sleep interval of respectively 15 and 10 seconds on NFS server and compiling host (because of clock skew values). This test failed. In the successful test, clock skew was usually below 500μs, only exceeded 1ms twice where it exceeded 1400μs. This bug triggered by distcc warnings is currently patched via ebuild. I've created an MR to upstream that patch: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9574 But, this error message will keep getting triggered by other random warning in future, as Felix has explained. distcc patch has been merged upstream and included in 3.30.0 milestone. (In reply to martin-kokos from comment #21) > distcc patch has been merged upstream and included in 3.30.0 milestone. Many thanks. commit 081ce359c916855eaf68dbe393687a091ca2ba72 Author: Sam James <sam@gentoo.org> Date: Wed Jul 3 03:09:39 2024 +0100 dev-build/cmake: add 3.30.0 Signed-off-by: Sam James <sam@gentoo.org> I'm hitting this same bug again with cmake-3.30.6, both with distcc and without (In reply to Ian Stakenvicius from comment #24) > I'm hitting this same bug again with cmake-3.30.6, both with distcc and > without Please file a new bug with the logs and we'll take a look. (In reply to Sam James from comment #25) > (In reply to Ian Stakenvicius from comment #24) > > I'm hitting this same bug again with cmake-3.30.6, both with distcc and > > without > > Please file a new bug with the logs and we'll take a look. I worked around it locally by applying the CMakeLists.txt patch. I’m not going to undo it to generate logs but I’ll report back with logs on a new bug if it persists on the next version bump. Alright then. |
