Opened 5 months ago

Last modified 41 hours 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:

https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/258542/steps/install-port/logs/stdio

/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 5 months ago by Koston-0xDEADBEEF

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.

comment:2 Changed 41 hours 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.

Note: See TracTickets for help on using tickets.