Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can't compile, #4

Open
aryx opened this issue Jun 6, 2011 · 41 comments
Open

can't compile, #4

aryx opened this issue Jun 6, 2011 · 41 comments

Comments

@aryx
Copy link

aryx commented Jun 6, 2011

g++ -c -o agramlex.yy.o agramlex.yy.cc -g -Wall -Wno-deprecated -D__UNIX__ -DNDEBUG -D__LINUX__ -I../smbase
In file included from ../smbase/sm_flexlexer.h:28,
from agramlex.yy.cc:247:
/usr/local/include/FlexLexer.h:130: error: expected unqualified-id before numeric constant
agramlex.yy.cc: In member function ‘virtual int GrammarLexer::yylex()’:
agramlex.yy.cc:640: error: ‘yy_current_buffer’ was not declared in this scope
agramlex.yy.cc:1087: error: ‘yy_current_buffer’ was not declared in this scope
agramlex.yy.cc:1110: error: ‘yy_current_buffer’ was not declared in this scope

my g++ is: 4.4.0
flex 2.5.4
bison 2.3

@dsw
Copy link
Owner

dsw commented Jul 5, 2011

Sorry to take so long getting back to you. Your versions of flex and
bison look fine, but I've never tried with this version of gcc.

This looks like some oddity in your FlexLexer.h or some disagreement
between the author of FlexLexer.h and the implementors of your version
of gcc as to what is C++ (not an unusual occurrence). Just stare at
it and see what your compiler doesn't like about it.

On Sun, Jun 5, 2011 at 9:30 PM, aryx
[email protected]
wrote:

g++ -c -o agramlex.yy.o agramlex.yy.cc -g -Wall -Wno-deprecated -D__UNIX__ -DNDEBUG -D__LINUX__ -I../smbase
In file included from ../smbase/sm_flexlexer.h:28,
                from agramlex.yy.cc:247:
/usr/local/include/FlexLexer.h:130: error: expected unqualified-id before numeric constant
agramlex.yy.cc: In member function ‘virtual int GrammarLexer::yylex()’:
agramlex.yy.cc:640: error: ‘yy_current_buffer’ was not declared in this scope
agramlex.yy.cc:1087: error: ‘yy_current_buffer’ was not declared in this scope
agramlex.yy.cc:1110: error: ‘yy_current_buffer’ was not declared in this scope

my g++ is: 4.4.0
flex 2.5.4
bison 2.3

Reply to this email directly or view it on GitHub:
#4

@manuels
Copy link

manuels commented Jun 12, 2012

modifying ast/agrampar.codes.h to

// # define YYTOKENTYPE <- commented!!!
# define YYSTYPE_IS_TRIVIAL 1
# define yystype YYSTYPE /* obsolescent; will be withdrawn */
# define YYSTYPE_IS_DECLARED 1
#include "agrampar.tab.h" // <- added!!!

worked for me

@dsw
Copy link
Owner

dsw commented Jun 12, 2012

I think bison just keeps changing in subtle and incompatible ways.
What we have checked in obviously compiles for us. We could apply
your changes and see if it continues to compile for us, but I'm not
sure there is one collection of settings that is going to be portable.

What kind of system are you building on?

Daniel

On Tue, Jun 12, 2012 at 1:12 PM, manuels
[email protected]
wrote:

modifying ast/agrampar.codes.h to

// # define YYTOKENTYPE <- commented!!!
# define YYSTYPE_IS_TRIVIAL 1
# define yystype YYSTYPE /* obsolescent; will be withdrawn */
# define YYSTYPE_IS_DECLARED 1
#include "agrampar.tab.h" // <- added!!!

worked for me


Reply to this email directly or view it on GitHub:
#4 (comment)

@manuels
Copy link

manuels commented Jun 12, 2012

I'm using Ubuntu 12.04:

  • gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
  • bison (GNU Bison) 2.5
  • flex 2.5.35

@dsw
Copy link
Owner

dsw commented Jun 12, 2012

Could you please send me the actual output of diff -u ?

Also, if you are contributing your patch to the project, please put in
the email "I hereby put the contents of this email, including any
attachments, into the public domain".

Daniel

On Tue, Jun 12, 2012 at 1:12 PM, manuels
[email protected]
wrote:

modifying ast/agrampar.codes.h to

// # define YYTOKENTYPE <- commented!!!
# define YYSTYPE_IS_TRIVIAL 1
# define yystype YYSTYPE /* obsolescent; will be withdrawn */
# define YYSTYPE_IS_DECLARED 1
#include "agrampar.tab.h" // <- added!!!

worked for me


Reply to this email directly or view it on GitHub:
#4 (comment)

@manuels
Copy link

manuels commented Jun 12, 2012

Here you are!
Please find the output of
$ git diff -u agrampar.tab.h agrampar.codes.h
attached to this email.

I hereby put the contents of this email, including any attachments, into
the public domain!

@dsw
Copy link
Owner

dsw commented Jun 12, 2012

Either you didn't attach it or github is discarding attachments.

You can email it to me at the email address in the image on my website
at http://daniel-wilkerson.appspot.com/ ; I don't want to put any more
machine-readable copies of my email on the internet than I have to.

Or you can do the standard github thing and fork the oink repo, make
the change, check it in, push to github, and then send me a pull
request.

On Tue, Jun 12, 2012 at 1:29 PM, manuels
[email protected]
wrote:

Here you are!
Please find the output of
$ git diff -u agrampar.tab.h agrampar.codes.h
attached to this email.

I hereby put the contents of this email, including any attachments, into
the public domain!


Reply to this email directly or view it on GitHub:
#4 (comment)

@msgolan
Copy link

msgolan commented Feb 13, 2013

I am having the same problem, but the suggested solution does not seem to work for me.

  • Env:
    cygwin
    gcc (GCC) 4.5.3
    flex 2.5.35
    bison (GNU Bison) 2.4.2
  • Scenario:
    $ git clone https://github.com/dsw/oink-stack.git
    $ cd oink-stack
    $ ./configure
    $ ./make
  • Error:
    agramlex.lex: In member function ‘virtual int GrammarLexer::yylex()’:
    agramlex.lex:126:22: error: ‘TOK_RBRACE’ was not declared in this scope
    agramlex.lex:127:22: error: ‘TOK_SEMICOLON’ was not declared in this scope
    ... (all the rest of the tokens)
  • After editing ast/agrampar.codes.h as suggested:
    agramlex.yy.cc:1624:14: error: ‘EOF’ was not declared in this scope
    Makefile:41: recipe for target `agramlex.yy.o' failed
  • I tried adding "#include <stdio.h>" to ast/agrampar.codes.h and it seems to work for the ast,
  • I then had to add corresponding corrections in elkhound/grampar.codes.h:
    . //# define YYTOKENTYPE <- commented
    . # define YYSTYPE_IS_TRIVIAL 1
    . # define yystype YYSTYPE /* obsolescent; will be withdrawn */
    . # define YYSTYPE_IS_DECLARED 1
    . #include "grampar.tab.h" // <- added
    . #include <stdio.h> // <- added
  • This too did not solve my issues. I now have the following error:
    In file included from grampar.y:8:0:
    grampar.h:7:34: fatal error: typ.h: No such file or directory
    compilation terminated.
    Makefile:157: recipe for target `grampar.tab.o' failed
  • Let me sum things up: HELP!

@dsw
Copy link
Owner

dsw commented Feb 13, 2013

I'm trying to work out if I can apply the patch sent to me by someone else
for this problem. Hold on.

Daniel

On Wed, Feb 13, 2013 at 7:36 AM, msgolan [email protected] wrote:

I am having the same problem, but the suggested solution does not seem to
work for me.

Info:
gcc (GCC) 4.5.3
flex 2.5.35
bison (GNU Bison) 2.4.2


Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-13499594.

@msgolan
Copy link

msgolan commented Feb 26, 2013

Any progress on this issue?

@dsw
Copy link
Owner

dsw commented Feb 26, 2013

I can't work on any Elsa/Oink issues until later next month.

On Tue, Feb 26, 2013 at 5:17 AM, msgolan [email protected] wrote:

Any progress on this issue?


Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-14112462
.

@msgolan
Copy link

msgolan commented Feb 27, 2013

Thanks, I'll hold my breath patiently, unless you think I can help with
this.
Shahar.

On Wed, Feb 27, 2013 at 1:01 AM, Daniel S. Wilkerson <
[email protected]> wrote:

I can't work on any Elsa/Oink issues until later next month.

On Tue, Feb 26, 2013 at 5:17 AM, msgolan [email protected]
wrote:

Any progress on this issue?


Reply to this email directly or view it on GitHub<
https://github.com/dsw/oink-stack/issues/4#issuecomment-14112462>
.


Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-14145568
.

@dsw
Copy link
Owner

dsw commented Jul 30, 2013

I'm sorry to say I just am not going to be working on this right now. The
best I can say is try an older version of the tools we depend on, such as
flex.

On Tue, Feb 26, 2013 at 10:29 PM, msgolan [email protected] wrote:

Thanks, I'll hold my breath patiently, unless you think I can help with
this.
Shahar.

On Wed, Feb 27, 2013 at 1:01 AM, Daniel S. Wilkerson <
[email protected]> wrote:

I can't work on any Elsa/Oink issues until later next month.

On Tue, Feb 26, 2013 at 5:17 AM, msgolan [email protected]
wrote:

Any progress on this issue?


Reply to this email directly or view it on GitHub<
https://github.com/dsw/oink-stack/issues/4#issuecomment-14112462>
.


Reply to this email directly or view it on GitHub<
https://github.com/dsw/oink-stack/issues/4#issuecomment-14145568>
.


Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-14159229
.

@msgolan
Copy link

msgolan commented Jul 30, 2013

Thanks Daniel,

I left Oink for the time, but I may retry in a few months.

Shahar.

On Tue, Jul 30, 2013 at 8:49 AM, Daniel S. Wilkerson <
[email protected]> wrote:

I'm sorry to say I just am not going to be working on this right now. The
best I can say is try an older version of the tools we depend on, such as
flex.

On Tue, Feb 26, 2013 at 10:29 PM, msgolan [email protected]
wrote:

Thanks, I'll hold my breath patiently, unless you think I can help with
this.
Shahar.

On Wed, Feb 27, 2013 at 1:01 AM, Daniel S. Wilkerson <
[email protected]> wrote:

I can't work on any Elsa/Oink issues until later next month.

On Tue, Feb 26, 2013 at 5:17 AM, msgolan [email protected]
wrote:

Any progress on this issue?


Reply to this email directly or view it on GitHub<
https://github.com/dsw/oink-stack/issues/4#issuecomment-14112462>
.


Reply to this email directly or view it on GitHub<
https://github.com/dsw/oink-stack/issues/4#issuecomment-14145568>
.


Reply to this email directly or view it on GitHub<
https://github.com/dsw/oink-stack/issues/4#issuecomment-14159229>
.


Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-21770934
.

@Earnestly
Copy link

Just to add my own experience as this seems similar:

  • bison (GNU Bison) 3.0.4
  • gcc (GCC) 4.9.2 20150304 (prerelease)
  • lex 2.5.39
  • flex 2.5.39
agrampar.tab.c: In function ‘int agrampar_yyparse()’:
agrampar.tab.c:1277:30: error: too few arguments to function ‘int agrampar_yylex(YYSTYPE*, void*)’
In file included from agrampar.y:8:0:
agrampar.h:59:5: note: declared here
 int agrampar_yylex(union YYSTYPE *lvalp, void *parseParam);
     ^
agrampar.y:117:39: error: ‘parseParam’ was not declared in this scope
                { $$ = *((ASTSpecFile**)parseParam) = new ASTSpecFile($1); }
                                       ^
In file included from agrampar.y:8:0:
agrampar.h:33:23: error: ‘parseParam’ was not declared in this scope
 #define YYPARSE_PARAM parseParam
                       ^
agrampar.h:56:40: note: in expansion of macro ‘YYPARSE_PARAM’
 #define yyerror(m) agrampar_yyerror(m, YYPARSE_PARAM)
                                        ^
agrampar.tab.c:1848:7: note: in expansion of macro ‘yyerror’
agrampar.h:33:23: error: ‘parseParam’ was not declared in this scope
 #define YYPARSE_PARAM parseParam
                       ^
agrampar.h:56:40: note: in expansion of macro ‘YYPARSE_PARAM’
 #define yyerror(m) agrampar_yyerror(m, YYPARSE_PARAM)
                                        ^
agrampar.tab.c:1992:3: note: in expansion of macro ‘yyerror’
Makefile:41: recipe for target 'agrampar.tab.o' failed
make[1]: *** [agrampar.tab.o] Error 1
make[1]: Leaving directory '/home/earnest/oink-stack/ast'
stack-scripts/Makefile:14: recipe for target 'all-rec' failed
make: *** [all-rec] Error 1

@dsw
Copy link
Owner

dsw commented Mar 25, 2015

I regret having to say this, but I just am not going to fix this bug right
now; I just have too many other important things to do. However, I will
point out that we get bug reports like this on a regular basis because the
tools we depend on, such as yacc and flex, keep wiggling in little annoying
ways. There is no way for us to prevent this and I am rather inclined to
not rely on these tools in the future. I don't know what the purpose is of
the maintainers of said tools in continuing to fuss with them and thereby
break client projects, but that seems to be what is happening. If anyone
fixes this bug and sends me a pull request, as long a the fix looks sane
and it builds and passes on my machine, I'll be happy to include it in the
mainline.

Daniel

On Mon, Mar 23, 2015 at 12:18 PM, Earnestly [email protected]
wrote:

Just to add my own experience as this seems similar:

  • bison (GNU Bison) 3.0.4
  • gcc (GCC) 4.9.2 20150304 (prerelease)
  • lex 2.5.39
  • flex 2.5.39

agrampar.tab.c: In function ‘int agrampar_yyparse()’:
agrampar.tab.c:1277:30: error: too few arguments to function ‘int agrampar_yylex(YYSTYPE_, void_)’
In file included from agrampar.y:8:0:
agrampar.h:59:5: note: declared here
int agrampar_yylex(union YYSTYPE lvalp, void *parseParam);
^
agrampar.y:117:39: error: ‘parseParam’ was not declared in this scope
{ $$ = *((ASTSpecFile
_)parseParam) = new ASTSpecFile($1); }
^
In file included from agrampar.y:8:0:
agrampar.h:33:23: error: ‘parseParam’ was not declared in this scope
#define YYPARSE_PARAM parseParam
^
agrampar.h:56:40: note: in expansion of macro ‘YYPARSE_PARAM’
#define yyerror(m) agrampar_yyerror(m, YYPARSE_PARAM)
^
agrampar.tab.c:1848:7: note: in expansion of macro ‘yyerror’
agrampar.h:33:23: error: ‘parseParam’ was not declared in this scope
#define YYPARSE_PARAM parseParam
^
agrampar.h:56:40: note: in expansion of macro ‘YYPARSE_PARAM’
#define yyerror(m) agrampar_yyerror(m, YYPARSE_PARAM)
^
agrampar.tab.c:1992:3: note: in expansion of macro ‘yyerror’
Makefile:41: recipe for target 'agrampar.tab.o' failed
make[1]: *_* [agrampar.tab.o] Error 1
make[1]: Leaving directory '/home/earnest/oink-stack/ast'
stack-scripts/Makefile:14: recipe for target 'all-rec' failed
make: *** [all-rec] Error 1


Reply to this email directly or view it on GitHub
#4 (comment).

@dsw
Copy link
Owner

dsw commented May 24, 2015

I just built and ran tests for the whole of oink-stack on Ubuntu 14.04 and it worked end to end out of the box. Are you still having difficulties?

@Earnestly
Copy link

It still fails to build here, slightly new error:

g++ -c -o grampar.o grampar.cc -g -Wall -Wno-deprecated -D__UNIX__ -DUSE_ENDSOURCELOC=1 -O2 -DNDEBUG -D__LINUX__ -I. -I../smbase -I../ast -Ic -fno-strict-aliasing
bison -d -v grampar.y
grampar.y:62.1-12: warning: deprecated directive, use ‘%pure-parser’ [-Wdeprecated]
 %pure_parser
 ^^^^^^^^^^^^
mv grampar.tab.c grampar.tab.c.orig
sed -e 's/YYSTYPE yyval;/YYSTYPE yyval = {0};/' \
    -e 's/__attribute__ ((__unused__))//' \
  <grampar.tab.c.orig >grampar.tab.c
rm grampar.tab.c.orig
g++ -c -g -o grampar.tab.o -g -Wall -Wno-deprecated -D__UNIX__ -DUSE_ENDSOURCELOC=1 -O2 -DNDEBUG -D__LINUX__ -I. -I../smbase -I../ast -Ic -fno-strict-aliasing -O2 -DNDEBUG -Wall  grampar.tab.c
grampar.tab.c:1301:30: error: macro "yylex" requires 2 arguments, but only 1 given
       yychar = yylex (&yylval);
                              ^
grampar.tab.c: In function ‘int grampar_yyparse()’:
grampar.tab.c:1301:16: error: ‘yylex’ was not declared in this scope
       yychar = yylex (&yylval);
                ^
grampar.y:163:22: error: ‘parseParam’ was not declared in this scope
                { ((ParseParams*)parseParam)->treeTop = new GrammarAST($1); $$=0; }
                      ^
grampar.y:38:30: error: ‘parseParam’ was not declared in this scope
 #define PARAM ((ParseParams*)parseParam)
                              ^
grampar.y:52:32: note: in expansion of macro ‘PARAM’
   new LocString(otherLoc->loc, PARAM->lexer.strtable.add(str))
                                ^
grampar.y:218:73: note: in expansion of macro ‘sameloc’
grampar.y:38:30: error: ‘parseParam’ was not declared in this scope
 #define PARAM ((ParseParams*)parseParam)
                              ^
grampar.y:52:32: note: in expansion of macro ‘PARAM’
   new LocString(otherLoc->loc, PARAM->lexer.strtable.add(str))
                                ^
grampar.y:326:36: note: in expansion of macro ‘sameloc’
 RHSElt: TOK_NAME                { $$ = new RH_name(sameloc($1, ""), $1); }
                                    ^
grampar.y:38:30: error: ‘parseParam’ was not declared in this scope
 #define PARAM ((ParseParams*)parseParam)
                              ^
grampar.y:52:32: note: in expansion of macro ‘PARAM’
   new LocString(otherLoc->loc, PARAM->lexer.strtable.add(str))
                                ^
grampar.y:328:38: note: in expansion of macro ‘sameloc’
       | TOK_STRING              { $$ = new RH_string(sameloc($1, ""), $1); }
                                      ^
In file included from grampar.y:8:0:
grampar.h:26:23: error: ‘parseParam’ was not declared in this scope
 #define YYPARSE_PARAM parseParam
                       ^
grampar.y:29:43: note: in expansion of macro ‘YYPARSE_PARAM’
 #define yyerror(msg) grampar_yyerror(msg, YYPARSE_PARAM)
                                           ^
grampar.tab.c:1779:7: note: in expansion of macro ‘yyerror’
       yyerror (YY_("syntax error"));
       ^
grampar.h:26:23: error: ‘parseParam’ was not declared in this scope
 #define YYPARSE_PARAM parseParam
                       ^
grampar.y:29:43: note: in expansion of macro ‘YYPARSE_PARAM’
 #define yyerror(msg) grampar_yyerror(msg, YYPARSE_PARAM)
                                           ^
grampar.tab.c:1923:3: note: in expansion of macro ‘yyerror’
   yyerror (YY_("memory exhausted"));
   ^
Makefile:157: recipe for target 'grampar.tab.o' failed
make[1]: *** [grampar.tab.o] Error 1
make[1]: Leaving directory '/home/earnest/build/lab/oink-git/src/oink-stack/elkhound'
stack-scripts/Makefile:14: recipe for target 'all-rec' failed
make: *** [all-rec] Error 1

@dsw
Copy link
Owner

dsw commented May 26, 2015

As I said, it works on Ubuntu 14.04. I'm only going to maintain it on one
platform. You could argue that should be a mainline platform, and I claim
that Ubuntu is one such. So feel free to debug it on your platform and
then suggest changes to Elsa/Oink that will make it work on both; if such
changes do not break it on my machine, I will consider incorporating them.

On Mon, May 25, 2015 at 6:12 PM, Earnestly [email protected] wrote:

It still fails to build here, slightly new error:

g++ -c -o grampar.o grampar.cc -g -Wall -Wno-deprecated -D__UNIX__ -DUSE_ENDSOURCELOC=1 -O2 -DNDEBUG -D__LINUX__ -I. -I../smbase -I../ast -Ic -fno-strict-aliasing
bison -d -v grampar.y
grampar.y:62.1-12: warning: deprecated directive, use ‘%pure-parser’ [-Wdeprecated]
%pure_parser
^^^^^^^^^^^^
mv grampar.tab.c grampar.tab.c.orig
sed -e 's/YYSTYPE yyval;/YYSTYPE yyval = {0};/'
-e 's/attribute ((unused))//'
<grampar.tab.c.orig >grampar.tab.c
rm grampar.tab.c.orig
g++ -c -g -o grampar.tab.o -g -Wall -Wno-deprecated -D__UNIX__ -DUSE_ENDSOURCELOC=1 -O2 -DNDEBUG -D__LINUX__ -I. -I../smbase -I../ast -Ic -fno-strict-aliasing -O2 -DNDEBUG -Wall grampar.tab.c
grampar.tab.c:1301:30: error: macro "yylex" requires 2 arguments, but only 1 given
yychar = yylex (&yylval);
^
grampar.tab.c: In function ‘int grampar_yyparse()’:
grampar.tab.c:1301:16: error: ‘yylex’ was not declared in this scope
yychar = yylex (&yylval);
^
grampar.y:163:22: error: ‘parseParam’ was not declared in this scope
{ ((ParseParams_)parseParam)->treeTop = new GrammarAST($1); $$=0; }
^
grampar.y:38:30: error: ‘parseParam’ was not declared in this scope
#define PARAM ((ParseParams_)parseParam)
^
grampar.y:52:32: note: in expansion of macro ‘PARAM’
new LocString(otherLoc->loc, PARAM->lexer.strtable.add(str))
^
grampar.y:218:73: note: in expansion of macro ‘sameloc’
grampar.y:38:30: error: ‘parseParam’ was not declared in this scope
#define PARAM ((ParseParams_)parseParam)
^
grampar.y:52:32: note: in expansion of macro ‘PARAM’
new LocString(otherLoc->loc, PARAM->lexer.strtable.add(str))
^
grampar.y:326:36: note: in expansion of macro ‘sameloc’
RHSElt: TOK_NAME { $$ = new RH_name(sameloc($1, ""), $1); }
^
grampar.y:38:30: error: ‘parseParam’ was not declared in this scope
#define PARAM ((ParseParams_)parseParam)
^
grampar.y:52:32: note: in expansion of macro ‘PARAM’
new LocString(otherLoc->loc, PARAM->lexer.strtable.add(str))
^
grampar.y:328:38: note: in expansion of macro ‘sameloc’
| TOK_STRING { $$ = new RH_string(sameloc($1, ""), $1); }
^
In file included from grampar.y:8:0:
grampar.h:26:23: error: ‘parseParam’ was not declared in this scope
#define YYPARSE_PARAM parseParam
^
grampar.y:29:43: note: in expansion of macro ‘YYPARSE_PARAM’
#define yyerror(msg) grampar_yyerror(msg, YYPARSE_PARAM)
^
grampar.tab.c:1779:7: note: in expansion of macro ‘yyerror’
yyerror (YY_("syntax error"));
^
grampar.h:26:23: error: ‘parseParam’ was not declared in this scope
#define YYPARSE_PARAM parseParam
^
grampar.y:29:43: note: in expansion of macro ‘YYPARSE_PARAM’
#define yyerror(msg) grampar_yyerror(msg, YYPARSE_PARAM)
^
grampar.tab.c:1923:3: note: in expansion of macro ‘yyerror’
yyerror (YY_("memory exhausted"));
^
Makefile:157: recipe for target 'grampar.tab.o' failed
make[1]: *** [grampar.tab.o] Error 1
make[1]: Leaving directory '/home/earnest/build/lab/oink-git/src/oink-stack/elkhound'
stack-scripts/Makefile:14: recipe for target 'all-rec' failed
make: *** [all-rec] Error 1


Reply to this email directly or view it on GitHub
#4 (comment).

@sarnold
Copy link

sarnold commented Aug 28, 2015

Not quite sure how it could build "out of the box" on ubuntu 14.04 since it fails with every version of Bison3 available in portage. AFAIK 14.0.4 ships with Bison3 package as current, and bison-old package for bison2. It definitely does build with Bison2 (2.7.1 in portage specifically) but not with Bison3. Lots of compiler warnings with current gcc version 4.9.3 (Gentoo 4.9.3 p1.0, pie-0.6.2) but it still builds, although I have not tested much yet (still in the to-do queue). Lastly perl-5.22 makes a new error in configure, which is fairly trivial to patch (patch in my portage-overlay). Hope this clears things up a little bit...

@dsw
Copy link
Owner

dsw commented Aug 28, 2015

Well feel free to fix these, release the changes into the public domain,
and send me a pull request. Again, I am not debugging/maintaining oink on
any platform other than the one I am running and on my vanilla Ubuntu 14.04
box, it builds and passes tests.

On Thu, Aug 27, 2015 at 5:45 PM, Steve Arnold [email protected]
wrote:

Not quite sure how it could build "out of the box" on ubuntu 14.04 since
it fails with every version of Bison3 available in portage. AFAIK 14.0.4
ships with Bison3 package as current, and bison-old package for bison2. It
definitely does build with Bison2 (2.7.1 in portage specifically) but
not with Bison3. Lots of compiler warnings with current gcc version 4.9.3
(Gentoo 4.9.3 p1.0, pie-0.6.2) but it still builds, although I have not
tested much yet (still in the to-do queue). Lastly perl-5.22 makes a new
error in configure, which is fairly trivial to patch (patch in my
portage-overlay). Hope this clears things up a little bit...


Reply to this email directly or view it on GitHub
#4 (comment).

@sarnold
Copy link

sarnold commented Aug 28, 2015

Then you must be using bison-old package? Or are you saying it works with bison3? I thought I was quite clear above; it will not compile with any of the versions in portage:

[-P-] [ ] sys-devel/bison-3.0.3-r1:0
[-P-] [ ] sys-devel/bison-3.0.4:0
[-P-] [ ] sys-devel/bison-3.0.4-r1:0

so it would be much more helpful for people in general, if you would just state explicitly what versions of the tools work for you "out of the box" on Ubuntu 14.0.4. Nobody else knows the dependencies better than you do; I can only report what I observe using a current toolchains and OS environments. The only version info I've seen from you so far is a reference to a really old version of apple gcc, and there's no way that one is current on Ubuntu. Repeatedly saying "builds out of the box on Ubuntu" is somewhat less than helpful. Might as well just script it...

Why are you so tight with the useful information? Especially when you seem to want everyone else to fix it for you because you "don't have time right now". Is that really true for each of these issues filed since 2011? (and public domain? really?!? what's up with that "requirement"? nobody else who did the work should get attribution?)

@sarnold
Copy link

sarnold commented Aug 28, 2015

Oh, thanks for the response to the other 4.5 year-old issue. It's a moot point now, obviously...

@dsw
Copy link
Owner

dsw commented Aug 28, 2015

On Thu, Aug 27, 2015 at 8:01 PM, Steve Arnold [email protected]
wrote:

. . .

it would be much more helpful for people in general, if you would just
state explicitly what versions of the tools work for you "out of the box"
on Ubuntu 14.0.4.

Oink-stack is a big project that has a lot of dependencies. Tools such as
gcc, flex, bision, etc. are being changed by their various maintainers all
the time and I am not going to constantly check on them. When I released
the project I recorded the dependencies as best as I could at the time. If
people want to send me updates to what is known about the dependencies that
work, I could incorporate those.

Elsa/Oink is one of those big complex projects that you really cannot use
without getting in to the internals and generally mucking about. It is not
like a car that, as long as you take it in for service on schedule or when
the check engine light comes on, you can expect it to "just work". It is
more like a box of tools and some partially assembled engines and things
that I can no longer really remember what they do, sort of like the Harry
Potter Room of Requirement: it saves you a lot of work from building it
yourself, but you still have to have the attitude like "I'm going to build
a compiler/analysis tool myself; oh, how helpful I don't have to build it
entirely from scratch". In fact, it is called "oink" because I thought of
it as a bucket into which to throw various sundry tools and a vision of a
bunch of pigs in a stye rolling around in the mud came to me. In like the
30's or 40's my maternal grandfather build an airplane from a kit and flew
it around. He was able to do this because he was an engineer and had his
own warehouse-sized workshop full of industrial grade tools. The plane
didn't have any instruments, so when they got lost in the fog in Chicago,
it was just luck that they didn't fly into a tall building or upside-down
into the ground without knowing it. The plane still exists and still
flies, though with a new engine. Oink-stack is a lot like that plane.
Anyway, until we are using languages that have a static analysis framework
baked into them from scratch, this is the situation.

Why are you so tight with the useful information?

I am not tight with useful information. If you wanted me to run bison
--version and email you the output the you could ask for that. Please ask
for what you want. I thought just saying that it works on Ubuntu 14.04
would be enough to help you; if not, ask specifically for what additional
information you need.

Here is what is says on my Ubuntu 14.04 machine where oink-stack build and
passes tests. I have done a few additional apt-get install-s that I do not
recall and unfortunately some of those apt-get install-s may have been done
after I last built oink-stack, so if this version doesn't work for you, I
could re-build to check everything.

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.1 LTS
Release: 14.04
Codename: trusty

$ bison --version
bison (GNU Bison) 3.0.2
. . .

Especially when you seem to want everyone else to fix it for you because

you "don't have time right now".

You seem to fundamentally mis-understand the situation. We have not signed
a support contract where I owe you or anyone else support. I put some
software on the internet along with lots of documentation and tests and my
best guess as to what dependencies worked at the time. Further, when I set
up my current Ubuntu dev machine, I checked that it still builds and passes
tests. Further, when people ask for help, I attempt to provide it.
However I have many other things I am doing, so as I am not personally
using oink-stack for anything right now and I have no contract with anyone
to maintain it, I am not tracking down any bugs that are not obvious to
me. Do note that doing so would be very expensive for me as task switching
costs a lot and I am working on several other projects as it is.

When someone asks me for something specific, I usually make an effort to
reply in a helpful way: for example, someone recently asked me how come
their analysis wasn't finding a bug; since I saw it was because they were
not doing a whole-program analysis, I sent them the make target which
demonstrates how to do that and the output I see when I run it on my
machine so they know what to expect; in theory they could have figured that
out from the docs, but I did it anyway. However, absent a contract, I am
under no obligation to do so. You speak as if I am. Please stop doing
that.

(and public domain? really?!? what's up with that "requirement"? nobody
else who did the work should get attribution?)

Again, you misunderstand the situation. Public domain is a concept from
the context of copyright: we do not accept contributions that have
copyright obligations attached to them and having contributors release
their contribution into the public domain satisfies that requirement. How
exactly we record that a change has been released into the public domain is
another point: saying so in a message attached to the pull request (if that
is possible) or sending me an email is what is occurring to me now.

Attribution is a separate issue. By making a change on github and then me
doing a git pull of your change you automatically get attribution by the
git mechanism of annotating each change with the author of the change.
This is why I like people to send me a pull request instead of, say,
emailing a patch: there is a record of exactly what happened. If someone
really started participating in maintaining the project, repeatedly fixing
bugs and/or adding features, I could list their name in the documentation
at the top as a contributor, perhaps with a note stating generally the
nature of their contribution. This is all pretty standard practice.

@sarnold
Copy link

sarnold commented Aug 28, 2015

Nobody asked for "constant checking", just a clear statement of the version that "works for you". Thanks.

@awgh
Copy link

awgh commented May 11, 2017

This same issue just happened to me with a fresh Ubuntu 17.04 install and a fresh checkout. Bison 3.0.4.

This thread is the first thing that pops up when searching for the error message. Anyone ever figure this out?

@dsw
Copy link
Owner

dsw commented May 11, 2017 via email

@sarnold
Copy link

sarnold commented May 20, 2017

I just fixed another build error in my Gentoo package, since FLEX_STD is now undefined it should be added to the CXXFLAGS in ast/Makefile.in (ie, g++ -DFLEX_STD) to make it build again. It now builds using the latest gcc 5.4 toolchain on Gentoo anyway, with the requirement that bison 2.7.1 is used instead of 3. The ebuild is here:

https://github.com/sarnold/portage-overlay/blob/master/dev-util/oink-stack/oink-stack-9999.ebuild

Some of the fixes may be helpful to get this compiled in a different environment.

@dsw
Copy link
Owner

dsw commented May 20, 2017 via email

@atamlir
Copy link

atamlir commented May 26, 2017

Can you share the vm image that works for you ?

@dsw
Copy link
Owner

dsw commented May 26, 2017 via email

@atamlir
Copy link

atamlir commented May 27, 2017

Thank you daniel, I am trying to replicate the same environment you have. What is your c++ compiler ?

@dsw
Copy link
Owner

dsw commented May 27, 2017 via email

@atamlir
Copy link

atamlir commented May 28, 2017

Thank you Daniel. All I had to do is :
download and install Ubuntu 14.04 LTS
sudo apt-get install bison=2:3.02.dfsg-2
sudo apt-get install flex=2.5.35-10.1ubuntu2
sudo apt-get install g++

Managed to run the QuickSample and the test.
Thank you!

@xaizek
Copy link

xaizek commented Oct 30, 2017

Here's a patch in case anyone else wants to compile this on more recent bison (3.0.4):

 elkhound/grampar.y | 9 ++++-----
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/elkhound/grampar.y b/elkhound/grampar.y
index 86b4981..3e9e414 100644
--- a/elkhound/grampar.y
+++ b/elkhound/grampar.y
@@ -18,15 +18,12 @@
   #define YYDEBUG 1
 #endif
 
-// name of extra parameter to yylex
-#define YYLEX_PARAM parseParam
-
 // make it call my yylex
 #define yylex(lv, param) grampar_yylex(lv, param)
 
 // Bison calls yyerror(msg) on error; we need the extra
 // parameter too, so the macro shoehorns it in there
-#define yyerror(msg) grampar_yyerror(msg, YYPARSE_PARAM)
+#define yyerror(param, msg) grampar_yyerror(msg, param)
 
 // rename the externally-visible parsing routine to make it
 // specific to this instance, so multiple bison-generated
@@ -59,7 +56,9 @@ AssocKind whichKind(LocString * /*owner*/ kind);
 
 /* ================== bison declarations =================== */
 // don't use globals
-%pure_parser
+%define api.pure full
+%lex-param {void *parseParam}
+%parse-param {void *parseParam}
 
 
 /* ===================== tokens ============================ */

make check doesn't pass, but at least everything compiles.

@dsw
Copy link
Owner

dsw commented Oct 30, 2017 via email

@noabody
Copy link

noabody commented May 12, 2018

To compile elkhound on Ubuntu 18.04 Bionic (flex-2.6.4, libfl-dev-2.6.4, bison-3.0.4, perl-5.26.1), I needed this patch and edits to ast/gramlex.cc and smbase/configure.pl.

WeiDUorg/elkhound@d422a26
smbase/configure.pl - add smbase to module path:
use lib '.';

ast/gramlex.cc - edit existing workaround for flex 2.5.31:
change [#ifdef FLEX_STD] to [#ifndef yy_current_buffer]

restrict build to elkhound only:

./configure
make -C smbase && make -C ast && make -C elkhound
strip -p elkhound/elkhound

Prerequisite elkhound binary is now prepared to be used for building weidu.
I realize that isn't the focus of this project but weidu is a a popular utility for the Infinity Engine games.

xaizek patch along with these changes:

diff --git a/ast/gramlex.cc b/ast/gramlex.cc
index 17be528..3288659 100644
--- a/ast/gramlex.cc
+++ b/ast/gramlex.cc
@@ -9,9 +9,9 @@
 #include <fstream>       // cout, ifstream
 
 
-// workaround for flex-2.5.31
-#ifdef FLEX_STD    // detect later versions of flex
-  // copied from flex's output
+// workaround for flex-2.5.31 and later
+#ifndef yy_current_buffer    // FlexLexer.h changed function
+  // check for macro definition
   #define YY_CURRENT_BUFFER ( (yy_buffer_stack) \
                             ? (yy_buffer_stack)[(yy_buffer_stack_top)] \
                             : NULL)
@@ -19,7 +19,7 @@
   // the 'yy_current_buffer' field was replaced by the buffer stack
   // alluded to above
   #define yy_current_buffer YY_CURRENT_BUFFER
-#endif // FLEX_STD
+#endif // yy_current_buffer
 
 
 // ----------------- GrammarLexer::AltReportError ---------------
diff --git a/elkhound/grampar.y b/elkhound/grampar.y
index 86b4981..7198526 100644
--- a/elkhound/grampar.y
+++ b/elkhound/grampar.y
@@ -18,15 +18,11 @@
   #define YYDEBUG 1
 #endif
 
-// name of extra parameter to yylex
-#define YYLEX_PARAM parseParam
-
 // make it call my yylex
 #define yylex(lv, param) grampar_yylex(lv, param)
 
-// Bison calls yyerror(msg) on error; we need the extra
-// parameter too, so the macro shoehorns it in there
-#define yyerror(msg) grampar_yyerror(msg, YYPARSE_PARAM)
+// Bison calls yyerror(<params>, msg) on error
+#define yyerror(param, msg) grampar_yyerror(msg, param)
 
 // rename the externally-visible parsing routine to make it
 // specific to this instance, so multiple bison-generated
@@ -59,7 +55,10 @@ AssocKind whichKind(LocString * /*owner*/ kind);
 
 /* ================== bison declarations =================== */
 // don't use globals
-%pure_parser
+%define api.pure full
+
+// extra parameter to both parser and lexer
+%param {void *parseParam}
 
 
 /* ===================== tokens ============================ */
diff --git a/smbase/configure.pl b/smbase/configure.pl
index 06b9678..7173f92 100755
--- a/smbase/configure.pl
+++ b/smbase/configure.pl
@@ -2,6 +2,7 @@
 # configure script for smbase
 
 use strict 'subs';
+use lib '.';
 
 require sm_config;
 

@dsw
Copy link
Owner

dsw commented May 15, 2018 via email

@noabody
Copy link

noabody commented May 15, 2018

#23 requires #21

@optikos
Copy link

optikos commented Dec 12, 2019

Were these pull requests ever submitted since 2017 & 2018? If so, were they applied here?

@dsw
Copy link
Owner

dsw commented Dec 16, 2019 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests