Problems with program_options using GCC 3.4 on FreeBSD
Hi Boosters, I've just tried building the program_options library, using GCC 3.4.1 on FreeBSD 4.8 and hit a couple of compilation errors. One error is caused by the platform, one by the compiler's stdlib. The first problem is line 116 in libs/program_options/src/utf8_codecvt_facet.cpp gcc-C++-action bin/boost/libs/program_options/build/libboost_program_options.a/gcc/debug/utf8_codecvt_facet.o /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp: In member function `virtual std::codecvt_base::result boost::program_options::detail::utf8_codecvt_facet_wchar_t::do_out(mbstate_t&, const wchar_t*, const wchar_t*, const wchar_t*&, char*, char*, char*&) const': /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: `WCHAR_MAX' undeclared (first use this function) /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: (Each undeclared identifier is reported only once for each function it appears in.) WCHAR_MAX is not defined by FreeBSD's wchar.h. Can boost::numeric_limits<wchar_t> be used instead? The second problem is visible because I built GCC with concept-checks enabled, which means the STL containers use a version of Boost's concept checks. This reveals that boost/program_options/options_description.hpp uses an incomplete type on line 232: gcc-C++-action bin/boost/libs/program_options/build/libboost_program_options.a/gcc/debug/options_description.o In file included from /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/options_description.cpp:9: /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/boost_concept_check.h: In instantiation of `__gnu_cxx::_SGIAssignableConcept<boost::program_options::options_description>': /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/stl_vector.h:144: instantiated from `std::vector<boost::program_options::options_description, std::allocator<boost::program_options::options_description> >' /data/development/jw/src/extcvs/boost/boost/program_options/options_description.hpp:232: instantiated from here /data/development/jw/gcc/3.4/bin/../lib/gcc/i386-unknown-freebsd4.8/3.4.1/../../../../include/c++/3.4.1/bits/boost_concept_check.h:216: error: `__gnu_cxx::_SGIAssignableConcept<_Tp>::__a' has incomplete type /data/development/jw/src/extcvs/boost/boost/program_options/options_description.hpp:142: error: forward declaration of `class boost::program_options::options_description' This error can be reproduced by compiling with -D_GLIBCXX_CONCEPT_CHECKS, or -D_GLIBCXX_DEBUG. Both the concept-checks and debug mode will reject std::vector< incomplete type >. jon -- "Nothing is true. Everything is permissible." - Hassan i Sabbah
Hi Jonathan,
I've just tried building the program_options library, using GCC 3.4.1 on FreeBSD 4.8 and hit a couple of compilation errors. One error is caused by the platform, one by the compiler's stdlib.
The first problem is line 116 in libs/program_options/src/utf8_codecvt_facet.cpp
/data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: `WCHAR_MAX' undeclared (first use this function) /data/development/jw/src/extcvs/boost/libs/program_options/build/../src/utf8_codecvt_facet.cpp:116: error: (Each undeclared identifier is reported only once for each function it appears in.)
WCHAR_MAX is not defined by FreeBSD's wchar.h. Can boost::numeric_limits<wchar_t> be used instead?
Does FreeBSD's wchar.h defines anything similiar? If not, could you indeed try using boost::numeric_limits. If it works, I'll make the change in CVS and see if this breaks anything else.
The second problem is visible because I built GCC with concept-checks enabled, which means the STL containers use a version of Boost's concept checks. This reveals that boost/program_options/options_description.hpp uses an incomplete type on line 232:
Hmmm.... the boiled down example is: class options_description { std::vector<options_description> groups; }; I'm really not sure what's going on there, because the standard does not say if instantinating a vector with incomplete type is allowed (or disallowed). Further, somehow the main regression tests have no problems.
This error can be reproduced by compiling with -D_GLIBCXX_CONCEPT_CHECKS, or -D_GLIBCXX_DEBUG. Both the concept-checks and debug mode will reject std::vector< incomplete type >.
For me only _GLIBCXX_CONCEPT_CHECKS triggers the error (on Debian). So the primary question: is it allowed to instantiate vector with incomplete type? If yes, it's a bug in g++, otherwise, it's a bug in program options. - Volodya
jon
On Wed, Jul 21, 2004 at 05:24:37PM +0400, Vladimir Prus wrote: Hi Volodya, thanks for the reply.
WCHAR_MAX is not defined by FreeBSD's wchar.h. Can boost::numeric_limits<wchar_t> be used instead?
Does FreeBSD's wchar.h defines anything similiar? If not, could you indeed try using boost::numeric_limits. If it works, I'll make the change in CVS and see if this breaks anything else.
No, it doesn't provide anything else, but using numeric_limits works for me, patch attached (will need testing for other compilers - I've only tested GCC 3.4 on FreeBSD). I don't think the boost:: qualification should be there in my patch, but does no harm.
The second problem is visible because I built GCC with concept-checks enabled, which means the STL containers use a version of Boost's concept checks. This reveals that boost/program_options/options_description.hpp uses an incomplete type on line 232:
Hmmm.... the boiled down example is:
class options_description { std::vector<options_description> groups; };
I'm really not sure what's going on there, because the standard does not say if instantinating a vector with incomplete type is allowed (or disallowed). Further, somehow the main regression tests have no problems.
This error can be reproduced by compiling with -D_GLIBCXX_CONCEPT_CHECKS, or -D_GLIBCXX_DEBUG. Both the concept-checks and debug mode will reject std::vector< incomplete type >.
For me only _GLIBCXX_CONCEPT_CHECKS triggers the error (on Debian). So the
Your testcase is different to the code that causes the error. Try this: #define _GLIBCXX_DEBUG #include <vector> class options_description; std::vector<options_description> groups; This fails for me. But, that might be because __gnu_debug::vector (incorrectly) has stricter requirements than std::vector.
primary question: is it allowed to instantiate vector with incomplete type? If yes, it's a bug in g++, otherwise, it's a bug in program options.
No, I'm pretty sure it's not - although I can't quote the standard right now. GCC's concept-checks and debug mode both require a complete type. The debug mode (by Doug Gregor IIRC) fails quite messily for the testcase above. jon -- "It is seldom that liberty of any kind is lost all at once." - David Hume
On Wed, Jul 21, 2004 at 03:29:00PM +0100, Jonathan Wakely wrote:
On Wed, Jul 21, 2004 at 05:24:37PM +0400, Vladimir Prus wrote:
Hi Volodya, thanks for the reply.
WCHAR_MAX is not defined by FreeBSD's wchar.h. Can boost::numeric_limits<wchar_t> be used instead?
Does FreeBSD's wchar.h defines anything similiar? If not, could you indeed try using boost::numeric_limits. If it works, I'll make the change in CVS and see if this breaks anything else.
No, it doesn't provide anything else, but using numeric_limits works for me, patch attached (will need testing for other compilers - I've only tested GCC 3.4 on FreeBSD). I don't think the boost:: qualification should be there in my patch, but does no harm.
Woah! no it doesn't - not with that patch, sorry! I thought the errors had gone, but bjam wasn't even getting that far (sorry, still getting used to figuring out bjam and it's output) Back to the drawing board .... jon -- "He who joyfully marches to music in rank and file has already earned my contempt. He has been given a large brain by mistake, since for him the spinal cord would fully suffice." - Albert Einstein
On Wed, Jul 21, 2004 at 03:36:06PM +0100, Jonathan Wakely wrote:
Woah! no it doesn't - not with that patch, sorry!
I thought the errors had gone, but bjam wasn't even getting that far (sorry, still getting used to figuring out bjam and it's output)
Back to the drawing board ....
OK, with this patch bjam _definitely_ produces utf8_codecvt_facet.o, which is the file that was failing. Sorry for the screw up (but I think it proves my point about needing to be tested by others on other compilers! how embarassing ...) jon -- "We are all in the gutter, but some of us are looking at the stars." - Oscar Wilde
Hi Jonathan,
On Wed, Jul 21, 2004 at 03:36:06PM +0100, Jonathan Wakely wrote:
Woah! no it doesn't - not with that patch, sorry!
I thought the errors had gone, but bjam wasn't even getting that far (sorry, still getting used to figuring out bjam and it's output)
Back to the drawing board ....
OK, with this patch bjam _definitely_ produces utf8_codecvt_facet.o, which is the file that was failing.
Sorry for the screw up (but I think it proves my point about needing to be tested by others on other compilers! how embarassing ...)
I've tested a slightly modified version (attached) on gcc 3.2, 3.3 and 3.4, as well as on borland 5.6.4 and VC7.1. The change is comitted, let's see what color regression pages will turn in ;-) Thanks, Volodya
On Wed, Jul 21, 2004 at 03:29:00PM +0100, Jonathan Wakely wrote:
primary question: is it allowed to instantiate vector with incomplete type? If yes, it's a bug in g++, otherwise, it's a bug in program options.
http://gcc.gnu.org/ml/gcc/2003-04/msg01516.html (and the reply) It would seem to be undefined behaviour, although I can't consult 17.3.4.6[2] right now. jon -- This space left intentionally blank.
On Wed, Jul 21, 2004 at 03:52:52PM +0100, Jonathan Wakely wrote:
On Wed, Jul 21, 2004 at 03:29:00PM +0100, Jonathan Wakely wrote:
primary question: is it allowed to instantiate vector with incomplete type? If yes, it's a bug in g++, otherwise, it's a bug in program options.
http://gcc.gnu.org/ml/gcc/2003-04/msg01516.html (and the reply)
It would seem to be undefined behaviour, although I can't consult 17.3.4.6[2] right now.
I believe that should be 17.4.3.6[2] [lib.res.on.functions] ^^^ A typo in the mail I cited. jon -- "All men naturally desire knowledge." - Aristotle
Jonathan Wakely wrote:
On Wed, Jul 21, 2004 at 03:52:52PM +0100, Jonathan Wakely wrote:
On Wed, Jul 21, 2004 at 03:29:00PM +0100, Jonathan Wakely wrote:
primary question: is it allowed to instantiate vector with incomplete type? If yes, it's a bug in g++, otherwise, it's a bug in program options.
http://gcc.gnu.org/ml/gcc/2003-04/msg01516.html (and the reply)
It would seem to be undefined behaviour, although I can't consult 17.3.4.6[2] right now.
I believe that should be 17.4.3.6[2] [lib.res.on.functions] ^^^ A typo in the mail I cited.
Thanks! I've corrected this problem. - Volodya
Jonathan Wakely <cow@compsoc.man.ac.uk> writes:
On Wed, Jul 21, 2004 at 03:29:00PM +0100, Jonathan Wakely wrote:
primary question: is it allowed to instantiate vector with incomplete type? If yes, it's a bug in g++, otherwise, it's a bug in program options.
http://gcc.gnu.org/ml/gcc/2003-04/msg01516.html (and the reply)
It would seem to be undefined behaviour, although I can't consult 17.3.4.6[2] right now.
It's definitely undefined behavior. You're not allowed to instantiate any std templates with undefined types. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (3)
-
David Abrahams -
Jonathan Wakely -
Vladimir Prus