can't compile,

[aryx]

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]

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: https://github.com/dsw/oink-stack/issues/4

[manuels]

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]

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: https://github.com/dsw/oink-stack/issues/4#issuecomment-6281313

[manuels]

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]

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: https://github.com/dsw/oink-stack/issues/4#issuecomment-6281313

[manuels]

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]

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: https://github.com/dsw/oink-stack/issues/4#issuecomment-6281822

[msgolan]

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]

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/dsw/oink-stack/issues/4#issuecomment-13499594.

[msgolan]

Any progress on this issue?

[dsw]

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/dsw/oink-stack/issues/4#issuecomment-14112462 .

[msgolan]

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/dsw/oink-stack/issues/4#issuecomment-14145568 .

[dsw]

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/dsw/oink-stack/issues/4#issuecomment-14159229 .

[msgolan]

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/dsw/oink-stack/issues/4#issuecomment-21770934 .

[Earnestly]

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]

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 https://github.com/dsw/oink-stack/issues/4#issuecomment-85155028.

[dsw]

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]

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]

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 https://github.com/dsw/oink-stack/issues/4#issuecomment-105346247.

[sarnold]

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]

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 https://github.com/dsw/oink-stack/issues/4#issuecomment-135593236.

[sarnold]

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]

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

[dsw]

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]

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

[awgh]

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]

Again, it works on Ubuntu 14.04 for me. When I update to a new version of Linux, I could always try it there. I do not want to mess with my system by trying out different versions of yacc trying to reproduce this bug. It seems to me that just using the exact same versions of flex and yacc as are the default on my version of Ubuntu should fix the problem. If not, I do not know how come.

On Wed, May 10, 2017 at 8:33 PM, awgh [email protected] wrote:

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?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dsw/oink-stack/issues/4#issuecomment-300673276, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC_XO441k7BTU6QcpZHod0YkLaWNEB6ks5r4oGggaJpZM4ABxNx .

[sarnold]

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]

Ok, well could I trouble you to just make those changes in oink-stack and push them and send me a pull request with a note saying that you "hereby release these changes into the public domain" ?

Daniel

On Sat, May 20, 2017 at 12:59 PM, Steve Arnold [email protected] wrote:

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.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dsw/oink-stack/issues/4#issuecomment-302895266, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC_XDLSG6rxL6wjPluYqrLmwVWRyjApks5r70YngaJpZM4ABxNx .

[atamlir]

Can you share the vm image that works for you ?