Here's my system specs (let me know if I'm leaving something out): SuSE Linux 8.2 gcc v. 3.3 barbet (juranich)$ g++ -v Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --enable-languages=c,c++,f77,objc,java,ada --disable-checking --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i486-suse-linux Thread model: posix gcc version 3.3 20030226 (prerelease) (SuSE Linux) flex v. 2.5.4 bison v. 1.75 Description of problem: When I cd into $BOOST/libs/graph/src and type 'make', I get the following errors: barbet:/local/src/boost_1_31_0/libs/graph/src # make flex -Pbgl_undir_ -ographviz_graph_lex.cpp graphviz_lex.ll bison -p bgl_undir_ -d -v -o graphviz_graph_parser.cpp graphviz_parser.yy graphviz_parser.yy: warning: 1 shift/reduce conflict g++ -ftemplate-depth-50 -DGRAPHVIZ_DIRECTED=0 -I../../.. -g -c graphviz_graph_lex.cpp graphviz_lex.ll: In function `int bgl_undir_lex(yystype*)': graphviz_lex.ll:85: error: request for member `ptr' in `*lvalp', which is of non-class type `int' graphviz_lex.ll:87: error: request for member `ptr' in `*lvalp', which is of non-class type `int' make: *** [graphviz_graph_lex.o] Error 1 So, line 85 in graphviz_lex.ll looks like this: I've looked at the source with a friend who (unlike myself) actually has some experience with lex and yacc, but he couldn't spot the problem either. I know that the caveat at the top of the file says that the makefile probably won't work on my system, so are there any suggestions on what I could do to make it work? Thanks a lot. -- Stephen W. Juranich Science Applications Intl. Corp. (SAIC) (520) 570-7706
Steve Juranich wrote: Hi Steve,
When I cd into $BOOST/libs/graph/src and type 'make', I get the following errors:
barbet:/local/src/boost_1_31_0/libs/graph/src # make flex -Pbgl_undir_ -ographviz_graph_lex.cpp graphviz_lex.ll bison -p bgl_undir_ -d -v -o graphviz_graph_parser.cpp graphviz_parser.yy graphviz_parser.yy: warning: 1 shift/reduce conflict g++ -ftemplate-depth-50 -DGRAPHVIZ_DIRECTED=0 -I../../.. -g -c graphviz_graph_lex.cpp graphviz_lex.ll: In function `int bgl_undir_lex(yystype*)': graphviz_lex.ll:85: error: request for member `ptr' in `*lvalp', which is of non-class type `int'
Strange. lvalp should have the type YYSTYPE, which should be declared in yystype.h. Would you mind running g++ -save-temps -ftemplate-depth-50 -DGRAPHVIZ_DIRECTED=0 -I../../.. -g -c graphviz_graph_lex.cpp and looking at preprocessing results (in graphviz_graph_lex.ii) and determining the real type of 'yylex' function parameter and 'lvalp' variable? - Volodya
On Tue, 16 Mar 2004, Vladimir Prus wrote:
Strange. lvalp should have the type YYSTYPE, which should be declared in yystype.h. Would you mind running
g++ -save-temps -ftemplate-depth-50 -DGRAPHVIZ_DIRECTED=0 -I../../.. -g -c graphviz_graph_lex.cpp
and looking at preprocessing results (in graphviz_graph_lex.ii) and determining the real type of 'yylex' function parameter and 'lvalp' variable?
Okay, this is something. On line 29176 of the .ii file, there's the following function definition that begins: int bgl_undir_lex(yystype* lvalp) { So, looking up the file I see 2 other occurrences of 'yystype'. The both occur in the following block: <snip> # 1 "yystype.h" 1 union YYSTYPE { int i; void* ptr; }; # 33 "graphviz_lex.ll" 2 # 41 "graphviz_lex.ll" # 1 "graphviz_graph_parser.hpp" 1 # 34 "graphviz_graph_parser.hpp" enum yytokentype { GRAPH_T = 258, NODE_T = 259, EDGE_T = 260, DIGRAPH_T = 261, EDGEOP_T = 262, SUBGRAPH_T = 263, ID_T = 264 }; # 56 "graphviz_graph_parser.hpp" typedef int yystype; </snip> So, it looks like yystype is an 'int'. Unfortunately, I'm kind of beyond the reach of my knowledge and experience, so I'll have to depend on others to tell me what to do next. Thanks a lot. -- Stephen W. Juranich Science Applications Intl. Corp. (SAIC) (520) 570-7706
Steve Juranich wrote:
union YYSTYPE { int i; void* ptr; }; # 33 "graphviz_lex.ll" 2 # 41 "graphviz_lex.ll" # 1 "graphviz_graph_parser.hpp" 1 # 34 "graphviz_graph_parser.hpp" enum yytokentype { GRAPH_T = 258, NODE_T = 259, EDGE_T = 260, DIGRAPH_T = 261, EDGEOP_T = 262, SUBGRAPH_T = 263, ID_T = 264 }; # 56 "graphviz_graph_parser.hpp" typedef int yystype; </snip>
Aha, for some reason, some magic which tells bison not to typedef int does not work.
So, it looks like yystype is an 'int'. Unfortunately, I'm kind of beyond the reach of my knowledge and experience, so I'll have to depend on others to tell me what to do next.
Could you look at two things: 1. Does yystype.h defines YYSTYPE_IS_DECLARED? 2. Does graphviz_graph_parser.hpp checks for any defines before typedefing? For me it has the following: #if ! defined (YYSTYPE) && ! defined (YYSTYPE_IS_DECLARED) typedef int YYSTYPE; # define yystype YYSTYPE /* obsolescent; will be withdrawn */ Maybe your version of bison uses some different macroses. - Volodya
On Tue, 16 Mar 2004, Vladimir Prus wrote:
Aha, for some reason, some magic which tells bison not to typedef int does not work.
So, it looks like yystype is an 'int'. Unfortunately, I'm kind of beyond the reach of my knowledge and experience, so I'll have to depend on others to tell me what to do next.
Could you look at two things:
1. Does yystype.h defines YYSTYPE_IS_DECLARED?
Yes. The definition happens on line 8 of yystype.h.
2. Does graphviz_graph_parser.hpp checks for any defines before typedefing? For me it has the following:
#if ! defined (YYSTYPE) && ! defined (YYSTYPE_IS_DECLARED) typedef int YYSTYPE; # define yystype YYSTYPE /* obsolescent; will be withdrawn */
Maybe your version of bison uses some different macroses.
My version of graphviz_graph_parser.hpp has the following (lines 55-58): #ifndef YYSTYPE typedef int yystype; # define YYSTYPE yystype #endif So it looks like the test is different as well as the #define arguments being switched around. When I changed my lines to match your lines, I was able to get the graphviz_graph_lex.o file, but the build chokes again when it tries to re-run with -DGRAPHVIZ_DIRECTED=1. Thanks for the help. -- Stephen W. Juranich Science Applications Intl. Corp. (SAIC) (520) 570-7706
participants (2)
-
Steve Juranich -
Vladimir Prus