Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Including Client Binding Headers Clashes with <sys/socket.h> #80

Open
kaehnd opened this issue Jun 2, 2023 · 1 comment
Open

Including Client Binding Headers Clashes with <sys/socket.h> #80

kaehnd opened this issue Jun 2, 2023 · 1 comment

Comments

@kaehnd
Copy link

kaehnd commented Jun 2, 2023

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.

Snippet of an example build error:

<root>/usr/include/sdbusplus/async/stdexec/at_coroutine_exit.hpp:95:24: error: reference to 'connect' is ambiguous
   95 |                 return connect((_Sender&&)__self.__sender_,
<root>/usr/include/sdbusplus/async/stdexec/execution.hpp:2003:39: note: candidates are: 'constexpr const stdexec::__connect::connect_t stdexec::connect'
 2003 | inline constexpr __connect::connect_t connect{};
      |                                       ^~~~~~~
<root>/usr/include/sys/socket.h:126:12: note:                 'int connect(int, const sockaddr*, socklen_t)'
  126 | extern int connect (int __fd, __CONST_SOCKADDR_ARG __addr, socklen_t __len);

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

@williamspatrick
Copy link
Member

I’ll have to relay this up to the stdexec project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants