Compilation fails with The C++ compiler does not support C++11 (e.g. std::unique_ptr). Succeeds with FEATURES=-distcc Portage 2.3.69 (python 3.6.5-final-0, !../../var/lib/overlays/vstone/profiles/vstone/server, gcc-8.3.0, glibc-2.29-r2, 5.2.2-gentoo x86_64) ================================================================= System uname: Linux-5.2.2-gentoo-x86_64-Intel-R-_Core-TM-_i7-8705G_CPU_@_3.10GHz-with-gentoo-2.6 KiB Mem: 32880896 total, 29147560 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Mon, 05 Aug 2019 11:47:31 +0000 Head commit of repository gentoo: d9e24c9c6b12a9f26fe36a7a74400f320f9285a8 Head commit of repository vstone: 274b790786818067f8263d19dfa47c0edf83a809 sh bash 4.4_p23-r1 ld GNU ld (Gentoo 2.31.1 p7) 2.31.1 distcc 3.3.2 x86_64-pc-linux-gnu [enabled] app-shells/bash: 4.4_p23-r1::gentoo dev-lang/perl: 5.28.2-r1::gentoo dev-lang/python: 2.7.15::gentoo, 3.6.5::gentoo dev-util/cmake: 3.14.6::gentoo sys-apps/baselayout: 2.6-r1::gentoo sys-apps/openrc: 0.41.2::gentoo sys-apps/sandbox: 2.13::gentoo sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r4::gentoo sys-devel/automake: 1.16.1-r1::gentoo sys-devel/binutils: 2.31.1-r6::gentoo, 2.32-r1::gentoo sys-devel/gcc: 8.3.0-r1::gentoo sys-devel/gcc-config: 2.0::gentoo sys-devel/libtool: 2.4.6-r3::gentoo sys-devel/make: 4.2.1-r4::gentoo sys-kernel/linux-headers: 4.19::gentoo (virtual/os-headers) sys-libs/glibc: 2.29-r2::gentoo Repositories: gentoo location: /usr/portage sync-type: git sync-uri: https://github.com/gentoo-mirror/gentoo.git priority: -1000 vstone location: /var/lib/overlays/vstone sync-type: git sync-uri: https://github.com/vStone/vstone-overlay.git masters: gentoo Installed sets: @emulation, @systemtools ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="@FREE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=skylake -mabm -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.2/ext-active/ /etc/php/apache2-php7.3/ext-active/ /etc/php/cgi-php7.2/ext-active/ /etc/php/cgi-php7.3/ext-active/ /etc/php/cli-php7.2/ext-active/ /etc/php/cli-php7.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=skylake -mabm -O2 -pipe" DISTDIR="/usr/portage/distfiles" ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-march=skylake -mabm -O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distcc distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-march=skylake -mabm -O2 -pipe" GENTOO_MIRRORS="https://mirror.leaseweb.com/gentoo/" LANG="en_US.utf8" LC_ALL="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en nl nl_BE" MAKEOPTS="-j17" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="acl amd64 berkdb btrfs bzip2 cli crypt cryptsetup cxx dri efi fortran gdbm git gpg iconv ipv6 libtirpc lvm lzma multilib ncurses nls nptl openmp pam pcre pcre16 readline seccomp split-usr ssl tcpd unicode vim-syntax xattr zlib" ABI_X86="64 32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" L10N="en nl" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-3" POSTGRES_TARGETS="postgres10 postgres11" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="intel amdgpu radeonsi" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CC, CPPFLAGS, CTARGET, CXX, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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.
See: https://forums.gentoo.org/viewtopic-p-8361378.html#8361378
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.
