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 :)
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 :)