You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Including <sys/socket.h> before any of the sdbusplus client binding headers now results in reference to 'connect' is ambiguous when building -- and further the using namespace stdexec; in the included chain propagates into all code using these header files, resulting in conflicts wherever connect is used without namespace scope.
I imagine this is a fairly common use-case, as including even something like including <boost/asio/steady_timer.hpp> pulls in socket.h and will run into the issue if it's pulled in before a client binding file.
Of course, the workaround of just including the client binding code first (or just before anything that pulls in socket.h) works, but I'm not sure how well that scales / if that's desirable.
I'm not necessarily sure if there is any possible/reasonable resolution to the issue, since it seems that the header files that pull in the using namespace stdexec are 3rd party -- just thought I'd report it in case it hadn't been seen by others yet :)
The text was updated successfully, but these errors were encountered:
Including
<sys/socket.h>
before any of the sdbusplus client binding headers now results inreference to 'connect' is ambiguous
when building -- and further theusing namespace stdexec;
in the included chain propagates into all code using these header files, resulting in conflicts whereverconnect
is used without namespace scope.Snippet of an example build error:
I imagine this is a fairly common use-case, as including even something like including
<boost/asio/steady_timer.hpp>
pulls insocket.h
and will run into the issue if it's pulled in before a client binding file.Of course, the workaround of just including the client binding code first (or just before anything that pulls in
socket.h
) works, but I'm not sure how well that scales / if that's desirable.I'm not necessarily sure if there is any possible/reasonable resolution to the issue, since it seems that the header files that pull in the
using namespace stdexec
are 3rd party -- just thought I'd report it in case it hadn't been seen by others yet :)The text was updated successfully, but these errors were encountered: