Hi all, while developing some code for Boost, I've had to add some more tests to the configuration headers so that BOOST_NO_STDC_NAMESPACE gets defined when some functions cannot be found (e.g., std::strdup, which is missing under NetBSD). This is irrelevant, because this symbol could get defined in a future by other changes in Boost. The problem is that when BOOST_NO_STDC_NAMESPACE is defined under NetBSD, Boost.Iostreams does not work any more and breaks the build of programs using it. Consider the following code example: ----- #define BOOST_NO_STDC_NAMESPACE #include <boost/iostreams/device/file_descriptor.hpp> int main(void) { return 0; } ----- When building it, I get: ----- $ g++ -I/home/jmmv/opt/include test.cc In file included from /home/jmmv/opt/include/boost/iostreams/positioning.hpp:19, from /home/jmmv/opt/include/boost/iostreams/device/file_descriptor.hpp:24, from test.cc:2: /home/jmmv/opt/include/boost/iostreams/detail/config/codecvt.hpp:70: error: ` codecvt' not declared ----- The problem arises because codecvt does not exist in the global namespace under NetBSD, although it does inside std::. Therefore, the 'using ::codecvt' line (the one that triggers the error) breaks the build. I don't know how this should be fixed, so I'm just sending a bug report. Maybe the BOOST_NO_STDC_NAMESPACE definition should be made more fine grained, so that defining it due to the lack of a function does not affect others that may exist? Should I file a bug report or is this message enough? Thanks, -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
Julio M. Merino Vidal wrote:
Hi all,
while developing some code for Boost, I've had to add some more tests to the configuration headers so that BOOST_NO_STDC_NAMESPACE gets defined when some functions cannot be found (e.g., std::strdup, which is missing under NetBSD).
Are there other examples? strdup is not standard C or C++, and the POSIX specification doesn't but it in namespace std (for obvious reasons) What standard library are you using?
This is irrelevant, because this symbol could get defined in a future by other changes in Boost.
The problem is that when BOOST_NO_STDC_NAMESPACE is defined under NetBSD, Boost.Iostreams does not work any more and breaks the build of programs using it. Consider the following code example:
The problem arises because codecvt does not exist in the global namespace under NetBSD, although it does inside std::. Therefore, the 'using ::codecvt' line (the one that triggers the error) breaks the build.
I don't know how this should be fixed, so I'm just sending a bug report. Maybe the BOOST_NO_STDC_NAMESPACE definition should be made more fine grained, so that defining it due to the lack of a function does not affect others that may exist?
This is a tricky problem, because defective standard libraries are not uniform in their bugginess, and the meaning of the boost defect macros is defined partly by how they are currently used in boost libraries. Since codecvt isn't a standard C library type, maybe I shouldn't be using BOOST_NO_STDC_NAMESPACE here. I borrowed the code in question from serialization. Unfortunately, the only way to tell which platforms need the using declaration would be to remove the code and see which tests fail. It's a bit too close to release to do that, I think.
Should I file a bug report or is this message enough?
It would be helpful if you give more information about your standard library and the parts of boost that fail to compile without defining BOOST_NO_STDC_NAMESPACE. Jonathan
Thanks,
On Sun, 2005-06-19 at 13:42 -0600, Jonathan Turkanis wrote:
Julio M. Merino Vidal wrote:
Hi all,
while developing some code for Boost, I've had to add some more tests to the configuration headers so that BOOST_NO_STDC_NAMESPACE gets defined when some functions cannot be found (e.g., std::strdup, which is missing under NetBSD).
Are there other examples? strdup is not standard C or C++, and the POSIX specification doesn't but it in namespace std (for obvious reasons)
What standard library are you using?
Sorry... I just assumed it had to be there, since other str functions are. My fault here.
I don't know how this should be fixed, so I'm just sending a bug report. Maybe the BOOST_NO_STDC_NAMESPACE definition should be made more fine grained, so that defining it due to the lack of a function does not affect others that may exist?
This is a tricky problem, because defective standard libraries are not uniform in their bugginess, and the meaning of the boost defect macros is defined partly by how they are currently used in boost libraries.
Yep, that's what I thought. This is why individual macros could be a better solution. Anyway, this seems too much change to solve this, at least for now ;)
Since codecvt isn't a standard C library type, maybe I shouldn't be using BOOST_NO_STDC_NAMESPACE here. I borrowed the code in question from serialization. Unfortunately, the only way to tell which platforms need the using declaration would be to remove the code and see which tests fail. It's a bit too close to release to do that, I think.
OK, I see.
Should I file a bug report or is this message enough?
It would be helpful if you give more information about your standard library and the parts of boost that fail to compile without defining BOOST_NO_STDC_NAMESPACE.
The thing is that nothing fails if BOOST_NO_STDC_NAMESPACE is undefined (NetBSD just uses plain gcc 3.3.3 ATM.) I was manually defining it because I incorrectly believed std::strdup existed. Thanks, -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/
participants (2)
-
Jonathan Turkanis -
Julio M. Merino Vidal