Opened 12 months ago

Last modified 11 months 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 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)

main.log (264.4 KB) - added by thetrial (alabay) 12 months ago.

Download all attachments as: .zip

Change History (10)

Changed 12 months ago by thetrial (alabay)

Attachment: main.log added

comment:1 Changed 12 months ago by judaew (Vadym-Valdis Yudaiev)

Cc: judaew added

comment:2 Changed 11 months ago by thetrial (alabay)

Hm, 4.4_1 … and the problem still persists. Any solutions in sight?

comment:3 Changed 11 months ago by thetrial (alabay)

With 4.4_2 whe still have that problem.

comment:4 Changed 11 months 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 11 months 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 11 months 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 11 months 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.

Last edited 11 months ago by kencu (Ken) (previous) (diff)

comment:8 Changed 11 months 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 11 months 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

found here https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl

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:

https://github.com/macports/macports-ports/blob/9d8ec313b4cea0c0f0b361a640fc66b8ec70978b/devel/ccache/Portfile#L42

Of course, if you do not have the current Portfile, then that is your trouble right there :>

Last edited 11 months ago by kencu (Ken) (previous) (diff)
Note: See TracTickets for help on using tickets.