-
Notifications
You must be signed in to change notification settings - Fork 34
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
Comments
Sorry to take so long getting back to you. Your versions of flex and This looks like some oddity in your FlexLexer.h or some disagreement On Sun, Jun 5, 2011 at 9:30 PM, aryx
|
modifying
worked for me |
I think bison just keeps changing in subtle and incompatible ways. What kind of system are you building on? Daniel On Tue, Jun 12, 2012 at 1:12 PM, manuels
|
I'm using Ubuntu 12.04:
|
Could you please send me the actual output of diff -u ? Also, if you are contributing your patch to the project, please put in Daniel On Tue, Jun 12, 2012 at 1:12 PM, manuels
|
Here you are! I hereby put the contents of this email, including any attachments, into |
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 Or you can do the standard github thing and fork the oink repo, make On Tue, Jun 12, 2012 at 1:29 PM, manuels
|
I am having the same problem, but the suggested solution does not seem to work for me.
|
I'm trying to work out if I can apply the patch sent to me by someone else Daniel On Wed, Feb 13, 2013 at 7:36 AM, msgolan [email protected] wrote:
|
Any progress on this issue? |
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:
|
Thanks, I'll hold my breath patiently, unless you think I can help with On Wed, Feb 27, 2013 at 1:01 AM, Daniel S. Wilkerson <
|
I'm sorry to say I just am not going to be working on this right now. The On Tue, Feb 26, 2013 at 10:29 PM, msgolan [email protected] wrote:
|
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 <
|
Just to add my own experience as this seems similar:
|
I regret having to say this, but I just am not going to fix this bug right Daniel On Mon, Mar 23, 2015 at 12:18 PM, Earnestly [email protected]
|
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? |
It still fails to build here, slightly new error:
|
As I said, it works on Ubuntu 14.04. I'm only going to maintain it on one On Mon, May 25, 2015 at 6:12 PM, Earnestly [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... |
Well feel free to fix these, release the changes into the public domain, On Thu, Aug 27, 2015 at 5:45 PM, Steve Arnold [email protected]
|
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 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?) |
Oh, thanks for the response to the other 4.5 year-old issue. It's a moot point now, obviously... |
On Thu, Aug 27, 2015 at 8:01 PM, Steve Arnold [email protected] . . .
Elsa/Oink is one of those big complex projects that you really cannot use
Here is what is says on my Ubuntu 14.04 machine where oink-stack build and $ lsb_release -a $ bison --version Especially when you seem to want everyone else to fix it for you because
When someone asks me for something specific, I usually make an effort to
Attribution is a separate issue. By making a change on github and then me |
Nobody asked for "constant checking", just a clear statement of the version that "works for you". Thanks. |
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? |
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 ***@***.***> 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
<#4 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC_XO441k7BTU6QcpZHod0YkLaWNEB6ks5r4oGggaJpZM4ABxNx>
.
|
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. |
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 ***@***.***> 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
<#4 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC_XDLSG6rxL6wjPluYqrLmwVWRyjApks5r70YngaJpZM4ABxNx>
.
|
Can you share the vm image that works for you ? |
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 ***@***.***> 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
<#4 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC_XLYTFwESP-20Kg7pF52sXLDDJQ_lks5r91qDgaJpZM4ABxNx>
.
|
Thank you daniel, I am trying to replicate the same environment you have. What is your c++ compiler ? |
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:
- gcc: 3.2, 3.4, 4.0, 4.1 known to work. gcc 2.95.3 no longer works
because our C code is no longer C89 compatible.
- flex: 2.5.4, 2.5.31, 2.5.33 known to work.
- bison: 1.35, 2.1, 2.3 known to work. NOTE: bison 2.4.1 known to not
work.
The oink-stack/platform-model repository requires the following:
- python2.4
The following are optional; you get extended functionality if you have
them.
- dot: 1.8.10, 2.7 known to work; Get dot from here:
http://www.graphviz.org/ <http://www.graphviz.org/> . You do not need
dot for the base functionality of the system. If we have an internal graph
to print out, such as the output of -fq-print-quals-graph, it will be
rendered out in dot format and you will need dot to convert that to
postscript.
- gcc-3.4 to use platform-model for C++ (Elsa does not support STL
headers from g++ 4.0 or g++ 3.3; please see platform-model/doc/gcc.txt.
- libzipios++ and zlib: libzipios++ 0.1.5.9 known to work, zlib 1.2.3
known to work. Enable loading and saving .qz archive files, in addition to
.qdir archive directories.
…On Sat, May 27, 2017 at 10:39 AM, atamlir ***@***.***> 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
<#4 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC_XCKs6Uvj7ehXJ4aAnRDo5DjmRJV7ks5r-F_lgaJpZM4ABxNx>
.
|
Thank you Daniel. All I had to do is : Managed to run the QuickSample and the test. |
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 ============================ */
|
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 ***@***.***> 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
<#4 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC_XJsiRCtdmSvZbRqhDUscAkciboW9ks5sxhIngaJpZM4ABxNx>
.
|
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 ast/gramlex.cc - edit existing workaround for flex 2.5.31: restrict build to elkhound only:
Prerequisite elkhound binary is now prepared to be used for building weidu. 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;
|
Can you make this a pull request?
…On Sat, May 12, 2018 at 7:39 AM, noabody ***@***.***> 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 <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/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
<#4 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAC_XO1wlHNN6twTClmql-tUb0DK4UnQks5txvQQgaJpZM4ABxNx>
.
|
Were these pull requests ever submitted since 2017 & 2018? If so, were they applied here? |
If you pull both 21 and 23, does everything work for you?
…On Thu, Dec 12, 2019 at 12:43 PM optikos ***@***.***> 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
<#4?email_source=notifications&email_token=AAAL6XG6OPKNAMH3LLXJMWTQYKPA5A5CNFSM4AAHCNY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGX7CWI#issuecomment-565178713>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAL6XG2B6MAIRKF7TBCGOLQYKPA5ANCNFSM4AAHCNYQ>
.
|
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
The text was updated successfully, but these errors were encountered: