search

dsw / oink-stack

Oink is a collaboration of C++ static analysis tools.
http://danielwilkerson.com/oink/index.html
153 stars 34 forks source link

can't compile, #4

Open aryx opened 13 years ago

aryx commented 13 years ago

g++ -c -o agramlex.yy.o agramlex.yy.cc -g -Wall -Wno-deprecated -DUNIX -DNDEBUG -DLINUX -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 commented 13 years ago

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 reply@reply.github.com wrote:

g++ -c -o agramlex.yy.o agramlex.yy.cc -g -Wall -Wno-deprecated -DUNIX -DNDEBUG -DLINUX -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 commented 12 years ago

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 commented 12 years ago

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 reply@reply.github.com 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 commented 12 years ago

I'm using Ubuntu 12.04:

dsw commented 12 years ago

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 reply@reply.github.com 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 commented 12 years ago

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 commented 12 years ago

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 reply@reply.github.com 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 commented 11 years ago

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

dsw commented 11 years ago

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 notifications@github.com 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 commented 11 years ago

Any progress on this issue?

dsw commented 11 years ago

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

On Tue, Feb 26, 2013 at 5:17 AM, msgolan notifications@github.com 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 commented 11 years ago

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 < notifications@github.com> wrote:

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

On Tue, Feb 26, 2013 at 5:17 AM, msgolan notifications@github.com 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 commented 11 years ago

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 notifications@github.com 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 < notifications@github.com> wrote:

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

On Tue, Feb 26, 2013 at 5:17 AM, msgolan notifications@github.com 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 commented 11 years ago

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 < notifications@github.com> 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 notifications@github.com 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 < notifications@github.com> wrote:

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

On Tue, Feb 26, 2013 at 5:17 AM, msgolan notifications@github.com 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 commented 9 years ago

Just to add my own experience as this seems similar:

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 commented 9 years ago

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 notifications@github.com 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 agramparyylex(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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 notifications@github.com wrote:

It still fails to build here, slightly new error:

g++ -c -o grampar.o grampar.cc -g -Wall -Wno-deprecated -DUNIX -DUSE_ENDSOURCELOC=1 -O2 -DNDEBUG -DLINUX -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 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 commented 9 years ago

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 commented 9 years ago

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 notifications@github.com 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 commented 9 years ago

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 commented 9 years ago

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

dsw commented 9 years ago

On Thu, Aug 27, 2015 at 8:01 PM, Steve Arnold notifications@github.com 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 commented 9 years ago

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

awgh commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 commented 7 years ago

Can you share the vm image that works for you ?

dsw commented 7 years ago

Ah, it's not a VM. I just have Ubuntu 14.04 installed on a desktop and I build and run there.

In case you want to know my versions of flex and yacc.

$ flex --version flex 2.5.35 $ yacc --version bison (GNU Bison) 3.0.2

On Fri, May 26, 2017 at 4:04 PM, atamlir notifications@github.com wrote:

Can you share the vm image that works for you ?

— 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-304405433, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC_XLYTFwESP-20Kg7pF52sXLDDJQ_lks5r91qDgaJpZM4ABxNx .

atamlir commented 7 years ago

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

dsw commented 7 years ago

I just rebuilt and re-checked oink-stack from scratch again and everything builds and all tests pass.

Here is some information on how my system is configured.

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

$ gcc --version gcc (Ubuntu 4.8.5-2ubuntu1~14.04.1) 4.8.5

$ g++ --version g++ (Ubuntu 4.8.5-2ubuntu1~14.04.1) 4.8.5

$ ar --version GNU ar (GNU Binutils for Ubuntu) 2.24

$ ranlib --version GNU ranlib (GNU Binutils for Ubuntu) 2.24

$ flex --version flex 2.5.35

$ bison --version bison (GNU Bison) 3.0.2

$ yacc --version bison (GNU Bison) 3.0.2 (yacc is just a script that runs bison)

$ perl --version This is perl 5, version 18, subversion 2 (v5.18.2) built for x86_64-linux-gnu-thread-multi (with 44 registered patches, see perl -V for more detail)

$ python --version Python 2.7.6

$ bash --version GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)

$ make --version GNU Make 3.81

Do note the oink website documentation: http://dsw.users.sonic.net/oink/

See the configuration instructions there.

See the notes on dependencies there, in particular, the below.

(1) 16 February 2011: Bison 2.4.1 does not work

(2) Dependencies required to compile Oink:

The oink-stack/platform-model repository requires the following:

The following are optional; you get extended functionality if you have them.

On Sat, May 27, 2017 at 10:39 AM, atamlir notifications@github.com wrote:

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

— 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-304466315, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC_XCKs6Uvj7ehXJ4aAnRDo5DjmRJV7ks5r-F_lgaJpZM4ABxNx .

atamlir commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Xaizek:

If this patch works, could you make this change and submit it as a pull request? If it works on my machine, I can then accept the request and it will be part of the mainline Oink.

I would rather do it this way than me just patch this on, as that way git is tracking the history correctly, namely that you wrote it.

On Mon, Oct 30, 2017 at 2:15 PM, xaizek notifications@github.com wrote:

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.

— 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-340536200, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC_XJsiRCtdmSvZbRqhDUscAkciboW9ks5sxhIngaJpZM4ABxNx .

noabody commented 6 years ago

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.

https://github.com/WeiDUorg/elkhound/commit/d422a2624bcbd1aa35116960e1f01fc10b77f168 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 commented 6 years ago

Can you make this a pull request?

On Sat, May 12, 2018 at 7:39 AM, noabody notifications@github.com wrote:

To compile elkhound on Ubuntu 18.04 Bionic (flex libfl-dev bison perl), I needed this patch and edits to gramlex.cc and configure.

configure edit, add smbase to module path: export PERL5LIB=$PWD/smbase

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

Patch format:

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 // 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/configure b/configure index 5365d1d..1a0d206 100755 --- a/configure +++ b/configure @@ -2,5 +2,7 @@

    dsw: Scott's configure startup script

    thunk

    +# add export for smbase module required by perl

+export PERL5LIB=$PWD/smbase exec perl -wS ./configure.pl ${1+"$@"}

— 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-388559547, or mute the thread https://github.com/notifications/unsubscribe-auth/AAC_XO1wlHNN6twTClmql-tUb0DK4UnQks5txvQQgaJpZM4ABxNx .

noabody commented 6 years ago

https://github.com/dsw/oink-stack/pull/23 requires https://github.com/dsw/oink-stack/pull/21

optikos commented 4 years ago

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

dsw commented 4 years ago

If you pull both 21 and 23, does everything work for you?

On Thu, Dec 12, 2019 at 12:43 PM optikos notifications@github.com wrote:

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

— 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?email_source=notifications&email_token=AAAL6XG6OPKNAMH3LLXJMWTQYKPA5A5CNFSM4AAHCNY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGX7CWI#issuecomment-565178713, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAL6XG2B6MAIRKF7TBCGOLQYKPA5ANCNFSM4AAHCNYQ .