[config] problem with sys/select.h on Linux/Unix
Hi, boost config seems to be indirectly including sys/select.h on Linux. This causing me a problem in my sockets library where I have my own declarations of select, fd_set etc which cause duplicate symbols errors. No only can I not use config but also any boost lib as they all use config :-(. Can someone please suggest a fix for this? Out of curiosity, why does config use select.h? regards /ikh -- "I disapprove of what you say, but I will defend to the death your right to say it," Evelyn Beatrice Hall who wrote under the pseudonym S.G. Tallentyre in a biography of Voltaire. #include <std_disclaimer>
boost config seems to be indirectly including sys/select.h on Linux. This causing me a problem in my sockets library where I have my own declarations of select, fd_set etc which cause duplicate symbols errors. No only can I not use config but also any boost lib as they all use config :-(.
Can someone please suggest a fix for this?
Out of curiosity, why does config use select.h?
It doesn't: at least not deliberately, my guess it's included by something else like <unistd.h> which we really do need. John.
Hi John, On Tue, 2009-06-30 at 18:16 +0100, John Maddock wrote: [ snip ]
It doesn't: at least not deliberately, my guess it's included by something else like <unistd.h> which we really do need.
Thanks for the reply, but unistd.h is not the culprit either directly or indirectly. Two possible candidates are sys/time.h and sys/types.h. Are either of these used directly or indirectly in boost config? Other boost libs document their dependencies. It would be useful if boost config documented the headers it includes, particularly as the C headers pollute the global namespace. Do you have any thoughts on a work around? It is awkward trying to write a library intended for submission to boost and not being able to use either config or the unit test framework. regards /ikh -- "I disapprove of what you say, but I will defend to the death your right to say it," Evelyn Beatrice Hall who wrote under the pseudonym S.G. Tallentyre in a biography of Voltaire. #include <std_disclaimer>
It doesn't: at least not deliberately, my guess it's included by something else like <unistd.h> which we really do need.
Thanks for the reply, but unistd.h is not the culprit either directly or indirectly. Two possible candidates are sys/time.h and sys/types.h. Are either of these used directly or indirectly in boost config?
Nope, just unistd.h limits.h and stdint.h as far as I can tell.
Other boost libs document their dependencies. It would be useful if boost config documented the headers it includes, particularly as the C headers pollute the global namespace.
Do you have any thoughts on a work around? It is awkward trying to write a library intended for submission to boost and not being able to use either config or the unit test framework.
OK here's the thing, it looks to me as though that header is very likely to be included even if it's by the users own code based on what you're saying? If so, then it's going to be important for you code and these system headers to happily live together, can you give an indication of what you're trying to do? Cheers, John. PS select.h appear to be pulled in via <cstddef> in select_stdlib_config.hpp.
Hi, On Wed, 2009-07-01 at 11:16 +0100, John Maddock wrote:
It doesn't: at least not deliberately, my guess it's included by something else like <unistd.h> which we really do need.
Thanks for the reply, but unistd.h is not the culprit either directly or indirectly. Two possible candidates are sys/time.h and sys/types.h. Are either of these used directly or indirectly in boost config?
Nope, just unistd.h limits.h and stdint.h as far as I can tell.
stdint.h pulls in sys/types.h
Other boost libs document their dependencies. It would be useful if boost config documented the headers it includes, particularly as the C headers pollute the global namespace.
Do you have any thoughts on a work around? It is awkward trying to write a library intended for submission to boost and not being able to use either config or the unit test framework.
OK here's the thing, it looks to me as though that header is very likely to be included even if it's by the users own code based on what you're saying?
If so, then it's going to be important for you code and these system headers to happily live together, can you give an indication of what you're trying to do?
I am trying to write a sockets library and the general admonishment has been to avoid macro infested system headers. Given time to think about it overnight, I have come to the same conclusion as you. That I am going to have to live with at least some these system headers. sys/types.h defines size_t which is pretty fundamental ;-). I guess I'll have to just undef the macros I need to exclude.
Cheers, John.
PS select.h appear to be pulled in via <cstddef> in select_stdlib_config.hpp.
Thanks for the help. Regards /ikh -- "I disapprove of what you say, but I will defend to the death your right to say it," Evelyn Beatrice Hall who wrote under the pseudonym S.G. Tallentyre in a biography of Voltaire. #include <std_disclaimer>
participants (2)
-
Iain K. Hanson -
John Maddock