Opened 3 years ago
Last modified 3 years ago
#63402 assigned defect
ccache @ 4.4_0 error: static_assert failed "unique_ptr constructed with null function pointer deleter"
Reported by: | thetrial (alabay) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.7.1 |
Keywords: | elcapitan legacy-os | Cc: | judaew (Vadym-Valdis Yudaiev) |
Port: | ccache |
Description
/Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:2579:13: error: static_assert failed "unique_ptr constructed with null function pointer deleter" :info:build static_assert(!is_pointer<deleter_type>::value, :info:build ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ :info:build /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/type_traits:2393:38: note: in instantiation of member function 'std::__1::unique_ptr<redisReply, void (*)(void *)>::unique_ptr' requested here :info:build : public integral_constant<bool, __is_constructible(_Tp, _Args...)> :info:build ^ :info:build /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/type_traits:2697:14: note: in instantiation of template class 'std::__1::is_constructible<std::__1::unique_ptr<redisReply, void (*)(void *)>>' requested here :info:build : public is_constructible<_Tp> :info:build ^ :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_ccache/ccache/work/ccache-4.4/src/third_party/nonstd/expected.hpp:1351:14: note: in instantiation of template class 'std::__1::is_default_constructible<std::__1::unique_ptr<redisReply, void (*)(void *)> >' requested here :info:build std::is_default_constructible<T>::value :info:build ^ :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_ccache/ccache/work/ccache-4.4/src/storage/secondary/RedisStorage.cpp:158:22: note: in instantiation of template class 'nonstd::expected_lite::expected<std::__1::unique_ptr<redisReply, void (*)(void *)>, storage::secondary::SecondaryStorage::Backend::Failure>' requested here :info:build const auto reply = redis_command("GET %s", key_string.c_str()); :info:build ^ :info:build 1 error generated.
Attachments (1)
Change History (10)
Changed 3 years ago by thetrial (alabay)
comment:1 Changed 3 years ago by judaew (Vadym-Valdis Yudaiev)
Cc: | judaew added |
---|
comment:2 Changed 3 years ago by thetrial (alabay)
comment:4 Changed 3 years ago by kencu (Ken)
the usual drill is to force a newer clang compiler on these mid-range systems.
Most of the systems <= 10.9 are forced to clang-9.0 or newer for builds that fail with the system clang already.
Systems 10.10 to 10.13 "used to usually work" with the system clang, but now newer versions of software use newer features of compilers, so things that used to work no longer do.
For a quick test, install clang-9.0 and force the build to that:
sudo port clean ccache sudo port -v -N install clang-9.0 sudo port -v install ccache configure.compiler=macports-clang-9.0
and if that works, report back.
Sometimes, if it is an important bootstrapping port, somebody might spend the time to find a way to fix the build using the older system compiler. I did that recently for cmake, for example, on 10.7 through 10.9.
Most of the time, that is a total waste of effort, and just blacklisting the old system clang is a much more efficient use of your limited time resources.
comment:5 Changed 3 years ago by thetrial (alabay)
I’ll try. I’m not sure if clang-9.0 wasn’t even installed before. The command sudo port -v -N install clang-9.0
hardly triggered something. Now I wait for the result of the latter.
comment:6 Changed 3 years ago by thetrial (alabay)
Wow, it ran through!
As I saw, clang-9.0 had been in my MP stuff. BTW, why 9 and not 12? And … what does this mean now?
comment:7 Changed 3 years ago by kencu (Ken)
clang-12 might have worked ... but compilers can be too new, as well as too old, and if they are too new they generate many errors that again make the build fail.
clang-9.0 is likely to have been installed (you had it, it appears) and it is, for now, just about perfect and builds 99% of software, being neither too old nor too new.
comment:8 Changed 3 years ago by thetrial (alabay)
Okay. So what is the quintessence of that? Is this something that should be fixed in the port/portfile, is this a rare case one has to use configure.compiler=macports-clang-9.0
or shall something be generally set in MP?
comment:9 Changed 3 years ago by kencu (Ken)
once we sort out exactly where the cutoff for the system clangs that can build ccache, we "blacklist" all the clangs older than the oldest one that works.
That involves a PortGroup, usually:
PortGroup compiler_blacklist_versions 1.0
and then an entry to spec the cutoff, whatever it is, something like this perhaps:
compiler.blacklist-append {clang < 800}
As it turns out, all that is already in the ccache Portfile, so assuming you have the current ccache Portfile, we just need to update the cutoff to the new level of failing compilers:
Of course, if you do not have the current Portfile, then that is your trouble right there :>
Hm, 4.4_1 … and the problem still persists. Any solutions in sight?