Opened 7 months ago
Last modified 7 weeks ago
#69739 assigned defect
input-leap @2.4.0-20231009: error: no viable conversion from returned value of type 'unique_ptr<inputleap::SecureSocket>' to function return type 'unique_ptr<inputleap::IDataSocket>'
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | Koston-0xDEADBEEF |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.9.3 |
Keywords: | Cc: | ||
Port: | input-leap |
Description
input-leap doesn't build on OS X 10.11 or earlier:
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_aqua_input-leap/input-leap/work/input-leap-edaa634551eb530a4ae6eaf1d31d62a72d70c961/src/lib/net/SecureListenSocket.cpp:55:16: error: no viable conversion from returned value of type 'unique_ptr<inputleap::SecureSocket>' to function return type 'unique_ptr<inputleap::IDataSocket>' return socket; ^~~~~~ /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:2553:29: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'std::unique_ptr<SecureSocket>' to 'const std::__1::unique_ptr<inputleap::IDataSocket, std::__1::default_delete<inputleap::IDataSocket> > &' for 1st argument class _LIBCPP_TYPE_VIS_ONLY unique_ptr ^ /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:2582:49: note: candidate constructor not viable: no known conversion from 'std::unique_ptr<SecureSocket>' to 'nullptr_t' for 1st argument _LIBCPP_INLINE_VISIBILITY _LIBCPP_CONSTEXPR unique_ptr(nullptr_t) _NOEXCEPT ^ /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:2609:31: note: candidate constructor not viable: no known conversion from 'std::unique_ptr<SecureSocket>' to 'std::__1::unique_ptr<inputleap::IDataSocket, std::__1::default_delete<inputleap::IDataSocket> > &&' for 1st argument _LIBCPP_INLINE_VISIBILITY unique_ptr(unique_ptr&& __u) _NOEXCEPT ^ /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:2613:9: note: candidate constructor [with _Up = inputleap::SecureSocket, _Ep = std::__1::default_delete<inputleap::SecureSocket>] not viable: no known conversion from 'std::unique_ptr<SecureSocket>' to 'unique_ptr<inputleap::SecureSocket, std::__1::default_delete<inputleap::SecureSocket> > &&' for 1st argument unique_ptr(unique_ptr<_Up, _Ep>&& __u, ^ /Library/Developer/CommandLineTools/usr/bin/../include/c++/v1/memory:2628:35: note: candidate template ignored: could not match 'auto_ptr' against 'unique_ptr' _LIBCPP_INLINE_VISIBILITY unique_ptr(auto_ptr<_Up>&& __p, ^ 1 error generated.
Since the version we're using is a several-months-old commit, maybe the first thing to try it to update to a newer commit.
Change History (2)
comment:1 Changed 7 months ago by Koston-0xDEADBEEF
comment:2 Changed 7 weeks ago by Koston-0xDEADBEEF
Alright, port has been updated, build system is much cleaner now and I took a closer look at this.
The bug is actually in OS X 10.11 SDK implementation of std::unique_ptr, which is a massive C++ template hell. I don't have enough sanity points (or time) to spend coming up with a reasonable solution for this, I'm afraid.
On the bright side, input-leap development has picked up a bit recently and one of the goals is ensuring backwards compatibility with barrier and even old synergy. It's always been compatible with barrier, but now guaranteeing compatibility is an explicit goal.
I suggest closing this ticket as "won't fix", instead encouraging OS X 10.11 users to use barrier instead and ensuring it remains in the ports tree for this purpose.
I'd rather just remove support for OS X versions prior to 10.12 for the time being, older platforms can use barrier instead. In fact, most people should use barrier instead since input-leap is still bleeding edge.
About updating the port: currently input-leap is having its build system cleaned up and reorganized upstream, once it's done and I have some spare time I will update the port and clean up macport end of the build.
There's also work being done (or at least planned) to better separate input-leap server/client from its GUI. Former should be much more portable than latter, so older OS X versions can also be supported again.