From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-06-19 14:42:56
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
> 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 list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk