[xpressive] compilation woes with gcc 3.3.3
compiling #include <boost/xpressive/regex_actions.hpp> fails with gcc version 3.3.3 (SuSE Linux) (running SuSE LES9) Any chance that might be fixed? Anything I can do about it?
Christoph Duelli wrote:
compiling
#include <boost/xpressive/regex_actions.hpp>
fails with gcc version 3.3.3 (SuSE Linux) (running SuSE LES9)
Any chance that might be fixed? Anything I can do about it?
This is a pretty old compiler, and I don't have easy access to it. I suppose if you posted the error messages I might be able to suss out a workaround. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Christoph Duelli wrote:
compiling
#include <boost/xpressive/regex_actions.hpp>
fails with gcc version 3.3.3 (SuSE Linux) (running SuSE LES9)
Any chance that might be fixed? Anything I can do about it?
This is a pretty old compiler, and I don't have easy access to it. I Yes, unfortunately we have machine with that old thing. Too bad... Always makes me happy when my code does not work on an older machine ;-) suppose if you posted the error messages I might be able to suss out a workaround. Thanks. I will do so once back at work.
However, as a first hint: I was able to compile my stuff after disabling (#if 0) the following -apparently not needed by me- parts in that header. Perhaps its an issue with BOOST_PROTO_DEFINE_FUNCTION_TEMPLATE. /// as (a.k.a., lexical_cast) /// BOOST_PROTO_DEFINE_FUNCTION_TEMPLATE( 1 , as , boost::proto::default_domain , (boost::proto::tag::function) , ((op::as)(typename)) ) /// static_cast_ /// BOOST_PROTO_DEFINE_FUNCTION_TEMPLATE( 1 , static_cast_ , boost::proto::default_domain , (boost::proto::tag::function) , ((op::static_cast_)(typename)) ) /// dynamic_cast_ /// BOOST_PROTO_DEFINE_FUNCTION_TEMPLATE( 1 , dynamic_cast_ , boost::proto::default_domain , (boost::proto::tag::function) , ((op::dynamic_cast_)(typename)) ) /// const_cast_ /// BOOST_PROTO_DEFINE_FUNCTION_TEMPLATE( 1 , const_cast_ , boost::proto::default_domain , (boost::proto::tag::function) , ((op::const_cast_)(typename)) ) Perhaps there was a compile problem with these, too: /// Usage: construct\<Type\>(arg1, arg2) /// BOOST_PROTO_DEFINE_VARARG_FUNCTION_TEMPLATE( construct , boost::proto::default_domain , (boost::proto::tag::function) , ((op::construct)(typename)) ) /// Usage: throw_\<Exception\>(arg1, arg2) /// BOOST_PROTO_DEFINE_VARARG_FUNCTION_TEMPLATE( throw_ , boost::proto::default_domain , (boost::proto::tag::function) , ((op::throw_)(typename)) ) (Can't check right now as someone has shut that machine down. I will on Monday, though!) For some reason, my "optional" constructs did not compile either. (I temp. replaced these by "| *_s"...) As I said, I will investigate the matter more next Monday. Best regards, and have a nice weekend Christoph
Christoph wrote: Ok, checked it: I did indeed #ifdef out the lines stated in the last post. As I have said, the above two sections in regex_actions.hpp cause trouble. Even including regex_actions.hpp causes the compiler to choke on it. (see gcc-out1.txt for compiling just the header *with* these sections not #ifdef'ed out. ) I have attached a few small demos that produce the remaining problem(s). The demo compiles (without warnings even) on gcc 4.1.2, it does not compile (and has some warnings on gcc 3.3.3). The compiler output of g++ test.cpp -I $BOOST_INC is attached ($BOOST_INC obv. points to the Boost 1.35 includes). ii) If I include some other headers that finally cause (internally!) to include boost/optional.hpp (which Boost header is not that important, <boost/format.hpp> is an example), I get (see gcc-out2.txt) Seems optional for some reason conflicts with boost::optional on gcc 3.3.3; if I do not include some other Boost Libs (which I am using in my code, too, like foreach, format) then the optional does compile. Writing boost::xpressive::optional fixes this. (As I said, that code compiles np on gcc 4.1.2) iii) I get some additional warnings like: boost/xpressive/traits/cpp_regex_traits.hpp:245: warning: comparison is always false due to limited range of data type (see gcc-out3.txt; also gcc-out2.txt) this warnings appear even if just doing sregex rx = _s; ) I hope, this information is enough to pinpoint potential issues. Best regards Christoph
Christoph Duelli wrote:
Ok, checked it: I did indeed #ifdef out the lines stated in the last post.
As I have said, the above two sections in regex_actions.hpp cause trouble. Even including regex_actions.hpp causes the compiler to choke on it. (see gcc-out1.txt for compiling just the header *with* these sections not #ifdef'ed out. ) <snip>
I can't tell from the logs. I'm building gcc-3.3.3 now and will investigate when that's done. -- Eric Niebler Boost Consulting www.boost-consulting.com
Eric Niebler wrote:
Christoph Duelli wrote:
Ok, checked it: I did indeed #ifdef out the lines stated in the last post.
As I have said, the above two sections in regex_actions.hpp cause trouble. Even including regex_actions.hpp causes the compiler to choke on it. (see gcc-out1.txt for compiling just the header *with* these sections not #ifdef'ed out. ) <snip>
I can't tell from the logs. I'm building gcc-3.3.3 now and will investigate when that's done.
Sorry, my gcc-3.3.3 build failed with: ../../gcc-3.3.3/gcc/gcc.c: In function `process_command': ../../gcc-3.3.3/gcc/gcc.c:3609: error: assignment of read-only location ../../gcc-3.3.3/gcc/gcc.c:3611: error: assignment of read-only location I'm giving up now. If you would like to pursue this, I would suggest you preprocess your test first and then reproduce the error. The line indicated by the error message contains a macro expansion. The error is somewhere in there. If you track it down and find a workaround, I'll gladly accept a patch. Good luck, -- Eric Niebler Boost Consulting www.boost-consulting.com
Sorry, my gcc-3.3.3 build failed with:
I think when I went through my first boost effort, I ended up getting an odd runtime problem ( unable to catch an exception ) until I switched compilers from the cygwin 3.3 version. I'm just pointing this out in case it is relevant and makes the effort you are discussing futile ( so it compiles but can't be reasonably made to run). Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: Hotmail is possibly blocking my mom's entire ISP - try me on marchywka@yahoo.com if no reply here. Thanks.
Date: Mon, 2 Jun 2008 10:21:37 -0700 From: eric@boost-consulting.com To: boost-users@lists.boost.org Subject: Re: [Boost-users] [xpressive] compilation woes with gcc 3.3.3
Eric Niebler wrote:
Christoph Duelli wrote:
Ok, checked it: I did indeed #ifdef out the lines stated in the last post.
As I have said, the above two sections in regex_actions.hpp cause trouble. Even including regex_actions.hpp causes the compiler to choke on it. (see gcc-out1.txt for compiling just the header *with* these sections not #ifdef'ed out. )
I can't tell from the logs. I'm building gcc-3.3.3 now and will investigate when that's done.
Sorry, my gcc-3.3.3 build failed with:
../../gcc-3.3.3/gcc/gcc.c: In function `process_command': ../../gcc-3.3.3/gcc/gcc.c:3609: error: assignment of read-only location ../../gcc-3.3.3/gcc/gcc.c:3611: error: assignment of read-only location
I'm giving up now. If you would like to pursue this, I would suggest you preprocess your test first and then reproduce the error. The line indicated by the error message contains a macro expansion. The error is somewhere in there. If you track it down and find a workaround, I'll gladly accept a patch.
Good luck,
-- Eric Niebler Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_________________________________________________________________ Make every e-mail and IM count. Join the i’m Initiative from Microsoft. http://im.live.com/Messenger/IM/Join/Default.aspx?source=EML_WL_ MakeCount
Eric Niebler wrote:
Eric Niebler wrote:
Christoph Duelli wrote:
Ok, checked it: I did indeed #ifdef out the lines stated in the last post.
As I have said, the above two sections in regex_actions.hpp cause trouble. Even including regex_actions.hpp causes the compiler to choke on it. (see gcc-out1.txt for compiling just the header *with* these sections not #ifdef'ed out. ) <snip>
I can't tell from the logs. I'm building gcc-3.3.3 now and will investigate when that's done.
Sorry, my gcc-3.3.3 build failed with:
../../gcc-3.3.3/gcc/gcc.c: In function `process_command': ../../gcc-3.3.3/gcc/gcc.c:3609: error: assignment of read-only location ../../gcc-3.3.3/gcc/gcc.c:3611: error: assignment of read-only location Probably a case of "when gcc 3.3.3 was developed, they used an elder, more forgiving C compiler." You're using a newer gcc (which finds more such issues) to compile an older compiler.
I'm giving up now. If you would like to pursue this, I would suggest you preprocess your test first and then reproduce the error. The line indicated by the error message contains a macro expansion. The error is somewhere in there. If you track it down and find a workaround, I'll gladly accept a patch.
Good luck, Thanks, I will need that ;-)
The warnings boost/xpressive/traits/cpp_regex_traits.hpp:245: warning: comparison is always false due to limited range of data type stem from template-code that is expanded to the following: (is_newline) char ch; return L'\r' == ch || L'\n' == ch || L'\f' == ch || (1 < SizeOfChar && ( 0x2028u == ch || 0x2029u == ch || 0x85u == ch)); Seems that gcc3.3.3 is not happy about the (ignored) checks. Well, I can live with that. (Not really happy, as I strive for warning free code... but as you rightly said: a rather old compiler.) When I find time to investigate Boost.Proto (otherwise my chances are rather slime), I will look into the other stuff and try to find out more. Best regards Christoph PS: The expanded macro stuff looks like that: error: syntax error before `,' token: template< typename X2_0, typename A0 > typename boost::proto::result_of::make_expr< boost::proto::tag::function , boost::proto::default_domain , op::as < X2_0 > const , const A0 >::type const as( const A0 &a0) { return boost::proto::result_of::make_expr< boost::proto::tag::function , boost::proto::default_domain , op::as < X2_0 > const , const A0 >::call( ( op::as < X2_0 >() ), a0 ); // <---- this line } and error: syntax error before `)' token: template< typename X2_0 > typename boost::proto::result_of::make_expr< boost::proto::tag::function , boost::proto::default_domain , op::construct < X2_0 > const >::type const construct() { return boost::proto::result_of::make_expr< boost::proto::tag::function , boost::proto::default_domain , op::construct < X2_0 > const >::call( ( op::construct < X2_0 >() ) ); // <----- this line } Perhaps it is obvious to someone else? (these two are typical of the errors)
Hi, I found something called SmartSOAP, curious to know if anyone here has an opinion. I'd prefer something that compiles ok with cygwin (not mingw ) that could eventually be moved to linux easily. It looks liek SmartSOAP is just a few header files and maybe a few source files that shouldn't be too hard to integrate but I'm not sure what I will encounter as any IO code can be quite surprising. http://smartwin.cvs.sourceforge.net/smartwin/SmartWin/ Thanks. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: Hotmail is possibly blocking my mom's entire ISP - try me on marchywka@yahoo.com if no reply here. Thanks. _________________________________________________________________ It’s easy to add contacts from Facebook and other social sites through Windows Live™ Messenger. Learn how. https://www.invite2messenger.net/im/?source=TXT_EML_WLH_LearnHow
participants (4)
-
Christoph -
Christoph Duelli -
Eric Niebler -
Mike Marchywka