out-of-line definition of 'LexerInput' does not match any declaration in 'yyFlexLexer'

[c9s]

I cloned your example, and run make, it shows:

mc_lexer.yy.cc:1023:18: error: out-of-line definition of 'LexerInput' does not match any declaration in 'yyFlexLexer'
int yyFlexLexer::LexerInput( char* buf, int /* max_size */ )
                 ^~~~~~~~~~
mc_lexer.yy.cc:1052:19: error: out-of-line definition of 'LexerOutput' does not match any declaration in 'yyFlexLexer'
void yyFlexLexer::LexerOutput( const char* buf, int size )
                  ^~~~~~~~~~~
2 errors generated.

[c9s]

$ bison --version
bison (GNU Bison) 3.0.2
Written by Robert Corbett and Richard Stallman.

$ flex --version
flex 2.5.37

[jonathan-beard]

Pedro,

I'll check it out in the morning, could simply be a versioning issue. Thanks for bringing it up! If you figure it out before I get back to you, please make the necessary updates to fix the issue.

Jonathan

On Jun 4, 2014, at 23:17, Pedro notifications@github.com wrote:

$ bison --version bison (GNU Bison) 3.0.2 Written by Robert Corbett and Richard Stallman.

$ flex --version flex 2.5.37

— Reply to this email directly or view it on GitHub.

[jonathan-beard]

I've tried to replicate the issue, I even downloaded and built the latest version of Bison (3.0.2). I'm assuming you're using the version checked out from GitHub and not a tgz'd version which was meant for backwards compatibility with Bison < 3.0? If not I'll try building on a Linux platform instead of OS X tonight. Any chance you can let me know the output of "uname -a" if you're on a Linux machine, or are you building with visual studio?

[jonathan-beard]

BTW, I compiled with both clang/clang++ (3.4) and icc/icpc(14.03). I'll try with gcc/g++ shortly.

[c9s]

Sorry for the late reply!

My platform: Darwin c9smba.local 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64

[c9s]

I guess it's caused by #ifdef YY_INTERACTIVE, which made the function prototype incompatible with the line below:

593 >---if ( (result = LexerInput( (char *) buf, max_size )) < 0 )

[c9s]

Seems like caused by this bug: https://bugs.launchpad.net/zorba/+bug/1034582

[c9s]

looks like a clang issue, because it builds successfully when I use gnu c++ compiler instead of clang:

   g++-mp-4.8 -Wno-deprecated-register -O0 -g -Wall -std=c++11 -c mc_lexer.yy.cc -o lexer.o

[c9s]

The flex-bison-cpp-example can build successfully without failure: http://panthema.net/2007/flex-bison-cpp-example/

And it has a self-included FlexLexer.h header file.

[jonathan-beard]

Yup, this is caused if you have your paths messed up. There’s always been an apple provided flex and bison….to fix this all you have to do is install a new version of Flex / Bison, ensure you have it installed in something like ‘/usr/local/bin’ with the include files in ‘/usr/local/include’. You’ll also have to make sure your path is set up with ‘/usr/local/‘ before ‘/usr/‘ If all else fails you can simply compile with ‘-I/usr/local/include/‘ which will take the correct version of the header file before the Apple provided one.

This problem is quite old, I just figured it was self explanatory to fix. Perhaps I’ll include a section on how to ‘fix’ Apple machines within the tutorial. The Flex header included by Apple really shouldn’t be used with C++….at least imho.

-Jonathan

On Jun 21, 2014, at 8:33 PM, Yo-An Lin notifications@github.com wrote:

https://bugs.launchpad.net/zorba/+bug/1034582

[jonathan-beard]

Looks like you’re building with a compiler that you compiled. I suspect your compiler has a different path setup than clang which is the issue at hand. One is checking ‘/usr/‘ first and the other is looking in ‘/usr/local/‘ first which it should. It’ll compile just fine with the apple provided clang, provided that the paths are setup correctly for the new headers. I tested on two different Macs then was able to replicate the issue. Simple fix, correct the paths...if you have a correct (non-Apple provided) version of Flex installed.

On Jun 21, 2014, at 9:03 PM, Yo-An Lin notifications@github.com wrote:

looks like a clang issue, because it builds successfully when I use gnu c++ compiler:

g++-mp-4.8 -Wno-deprecated-register -O0 -g -Wall -std=c++11 -c mc_lexer.yy.cc -o lexer.o

— Reply to this email directly or view it on GitHub.

[jonathan-beard]

I can also re-enable the bug on OS X by calling the wrong version of Flex….as in /usr/bin/flex within the Make file. So, I’d also verify your path has ‘/usr/local/bin/‘ before ‘/usr/bin’ by calling ‘echo $PATH’ through the terminal, alternatively you can check with ‘which flex’. If the one returned is not the one you’ve installed then you probably need to fix your path.

-Jonathan

On Jun 21, 2014, at 9:03 PM, Yo-An Lin notifications@github.com wrote:

looks like a clang issue, because it builds successfully when I use gnu c++ compiler:

g++-mp-4.8 -Wno-deprecated-register -O0 -g -Wall -std=c++11 -c mc_lexer.yy.cc -o lexer.o

— Reply to this email directly or view it on GitHub.

[jonathan-beard]

Even more fun, it looks like the definitions from the header file are compiled into the executable (i.e., the header must match the executable). Perhaps this code isn’t used by Flex, but it explains a lot. I’d recommend installing Flex from Sourceforge to get a correctly working executable, fix your path and you should be good to go for any modern Flex/Bison application. I’d leave the Apple one in place in case its used for any Apple specific utilities. The reason I recommend not going with the example that will compile with the Apple tools is that it won't necessarily work with any new version of Flex that you'll find on every other non-Apple machine.

-Jonathan

On Jun 21, 2014, at 9:03 PM, Yo-An Lin notifications@github.com wrote:

looks like a clang issue, because it builds successfully when I use gnu c++ compiler:

g++-mp-4.8 -Wno-deprecated-register -O0 -g -Wall -std=c++11 -c mc_lexer.yy.cc -o lexer.o

— Reply to this email directly or view it on GitHub.

[c9s]

Thanks, it helps a lot. :)

:+1: