I'm trying to get flex and bison working on my windows machine. I have installed flex, bison, and mingw compiler. i have a file named test.l in my flex bin folder that contains the following code:
%{
int chars = 0;
%}
%%
. { chars++; }
%%
main()
{
yylex();
printf("yay: %d", chars);
}
Flex is giving me nine bad character errors from line one, then a few "unknown error processing section 1" errors. Each line is about the same, give or take a few unknown character errors. Final error is premature EOF at the end of line 13.
Is this a sign that I have things installed incorrectly, or have I seriously messed up somewhere in this simple test file?
Related
I am having trouble writing a bison parser, and unexpectedly ran into difficulties getting the parser to print debug information. I found two solutions on the web, but neither seems to work.
This advocates to put this code in the main routine:
extern int yydebug;
yydebug = 1;
Unfortunately the C++ compiler detects an undefined reference to `yydebug'.
This suggests putting
#if YYDEBUG == 1
extern yydebug;
yydebug = 1;
#endif
into the grammar file. It compiles but does not produce output.
What does work is to edit the parser file itself, replacing
int yydebug;
by
int yydebug = 1;
The big disadvantage is that I have to redo this every time I change the grammar file, which during debugging would happen constantly. Is there any other way I can provoke the parser into coughing up its secret machinations?
I am using bison v2.4.1 to generate the parser, with the following command-line options:
bison -ldv -p osil -o $(srcdir)/OSParseosil.tab.cpp OSParseosil.y
Although the output is a C++ file, I am using the standard C skeleton.
With bison and the standard C skeleton, to enable debug support you need to do one of the following:
Use the -t (Posix) or --debug (Bison extension) command-line option when you create your grammar. (bison -t ...)
Use the -DYYDEBUG=1 command-line option (gcc or clang, at least) when you compile the generated grammar (gcc -DYYDEBUG=1 parser.tab.c ...`).
Add the %debug directive to your bison source
Put #define YYDEBUG 1 in the prologue in your bison source (the part of the file between %{ and %}.
I'd use -t in the bison command line. It's simple, and since it is Posix standard it probably will also work on other derived parser generators. However, adding %debug to the bison source is also simple; while it is not as portable, it works in bison 2.4.
Once you've done that, simply setting yydebug to a non-zero value is sufficient to produce debug output.
If you want to set yydebug in some translation unit other than the generated parser itself, you need to be aware of the parser prefix you declared in the bison command line. (In the parser itself, yydebug is #defined to the prefixed name.) And you need to declare the debug variable (with the correct prefix) as extern. So in your main, you probably want to use:
extern int osildebug;
// ...
int main(int argc, char** argv) {
osildebug = 1;
// ...
}
If you're using bison, your best place to find information is the bison manual; most of the above answer will be found in that page.
I am running Lua with a C++ library via swig. When a swig runtime error occurs I would like to know the line which caused the problem. The error message I receive does not have this information.
How can I find which line in the Lua code triggered the error?
For example suppose I have a swig function "swigstringcount" and it takes a string:
local n=4
local m=swigstringcount(n)
print (m,n)
This (obviously wrong) code produces an error on line two. Currently all I get is
error:SWIG_RuntimeError: swigstringcount requires a string
I want it to tell me that line 2 produced the error, like standard Lua error messages.
Based on this method for getting debug info from the Lua C API I've put together a (slightly messy) example of how you can integrate that into a SWIG interface:
%module test
%{
#undef SWIG_fail_arg
#define SWIG_fail_arg(func_name,argnum,type) \
{lua_Debug ar;\
lua_getstack(L, 1, &ar);\
lua_getinfo(L, "nSl", &ar);\
lua_pushfstring(L,"Error (%s:%d) in %s (arg %d), expected '%s' got '%s'",\
ar.source,ar.currentline,func_name,argnum,type,SWIG_Lua_typename(L,argnum));\
goto fail;}
%}
%include <std_string.i>
%inline %{
void func(const std::string& str) {}
%}
This basically replaces the default SWIG_fail_arg macro with a modified one that gets and prints some debug info.
I tested it with the latest SWIG trunk (I think you might be using an older version since the text I see didn't quite match), but I was able to do:
Lua 5.1.4 Copyright (C) 1994-2008 Lua.org, PUC-Rio
> require('test')
> local n=4
> test.func(n)
Error (=stdin:1) in func (arg 1), expected 'std::string const &' got 'nil'
stack traceback:
[C]: in function 'func'
stdin:1: in main chunk
[C]: ?
I seem to have more debug info (i.e. a full stack trace) there already though.
I have the following trivial Lua program which I copied from the book Programming In Lua
#include <stdio.h>
#include <lua.h>
#include <lauxlib.h>
#include <lualib.h>
int main (void)
{
char buff[256];
int error;
lua_State *L = luaL_newstate(); /* opens Lua */
luaL_openlibs(L); /* opens the standard libraries */
while (fgets(buff, sizeof(buff), stdin) != NULL)
{
error = luaL_loadbuffer(L, buff, strlen(buff), "line") ||
lua_pcall(L, 0, 0, 0);
if (error)
{
fprintf(stderr, "%s", lua_tostring(L, -1));
lua_pop(L, 1); /* pop error message from the stack */
}
}
lua_close(L);
return 0;
}
my environment is cywin
my make file looks like this:
CC=gcc
INCLUDE='-I/home/xyz/c_drive/Program Files/Lua/5.1/include'
LINKFLAGS='-L/home/xyz/c_drive/Program Files/Lua/5.1/lib' -llua51
li.o:li.c
$(CC) $(INCLUDE) -c li.c
main:li.o
$(CC) -o main $(LINKFLAGS) li.o
clean:
rm *.o
rm main
My /home/xyz/c_drive/Program Files/Lua/5.1/lib directory contains lua5.1.dll lua5.1.lib lua51.dll and lua51.lib
Trying to build my main target I am getting the following errors:
li.o:li.c:(.text+0x35): undefined reference to `_luaL_newstate'
li.o:li.c:(.text+0x49): undefined reference to `_luaL_openlibs'
li.o:li.c:(.text+0xaf): undefined reference to `_luaL_loadbuffer'
li.o:li.c:(.text+0xd9): undefined reference to `_lua_pcall'
li.o:li.c:(.text+0x120): undefined reference to `_lua_tolstring'
li.o:li.c:(.text+0x154): undefined reference to `_lua_settop'
li.o:li.c:(.text+0x167): undefined reference to `_lua_close'
Any ideas about what I might be doing wrong here?
The problem is that you have named the libraries on the link command line before the object files that require them. The linker loads modules from left to right on the command line. At the point on the line where you name -llua51, no undefined symbols that could be satisfied by that library are known. Then you name li.o, which does have unknown symbols.
Some Unix-like environments don't treat this as an error because part of the link process is deferred to the program load when reference to .so files are satisfied. But Cygwin, MinGW, and Windows in general must treat this as an error because DLLs work quite differently from .so files.
The solution is to put -llua51 after all the .o files on your link line.
Edit: Incidentally, it appears you are linking against the Lua for Windows distribution, but building with GCC under Cygwin. You will want to use Dependency Walker to make sure that your program does not depend on the Cygwin runtime, and that it does depend on the same C runtime as the lua51.dll from Lua for Windows. IIRC, that will be the runtime for the previous version of Visual Studio. It is possible to make GCC link against that, but you will need to be using the MinGW port (which you can use from Cygwin), and link against a couple of specific libraries to get that version. I'm away from my usual PC, or I'd quote an exact link line. (I believe you need -lmoldname -lmsvcr80 or something like that, as the last items on the link line.)
It will cause mysterious and very hard to diagnose problems if more than one C runtime library is in use. The easy answer is to use the same one as your preferred Lua DLL. Another alternative is that the Lua Binaries project has pre-compiled Lua DLLs for a wide array of C toolchains on Windows. If you need a Lua application that understands the Cygwin environment, you will want one that is built by GCC for Cygwin and not the Lua for Windows flavor. Lua Binaries will be your friend, or you can build Lua your self from source.
The names in the Lua API do not have those leading underscores. Try compiling with -fno-leading-underscore.
I'm still learning how to program but I have a simple question. I have the following code for running an executable COBOL program through C++, but I am getting COBOL errors: 251 and 410
#include <iostream>
#include <windows.h>
using namespace std;
int main(){
system("C:\\rmcobol\\runcobol.exe SOLOCAJA.COB c=windows.cfg L=WOWRT.DLL");
cout << "\n";
system("pause");
return 0;
}
I assume there must be a very simple reason for this, but I am clueless so far. Any help would be highly appreciated.
Error 410 is a "configuration file not found" error based on Apendix A of the user guide. Are you sure your windows.cfg file is in the directory you're running your code in?
Failing that, error 251 states "Incorrect runtime command" and all the samples I can find have an uppercase C. So maybe change your C program to use to:
system("C:\\rmcobol\\runcobol.exe SOLOCAJA.COB C=WINDOWS.CFG L=WOWRT.DLL");
and see if that fixes it (a long shot, I know, but I've seen stranger things than that).
Based on update:
I tried changing the c to a C on the C=WINDOWS.CFG, ran it in C++ and directly on the Command Line, no change. I am still looking into the reasons behind this, and I read through tek-tips.com/viewthread.cfm?qid=1119251&page=5 but I couldn't use any of that info. Any extra tips would be gold at this point. THANKS!
A couple of questions:
Has it ever worked in this environment?
Is it failing on both cmdline and within C (just want to clarify)?
Does windows.cfg actually exist in the current directory when you run it?
Are you running it in a directory with spaces (like My Documents)?
Other than that, maybe post the windows.cfg file, though the error seems pretty explicit that it's config file not found rather than error in config file.
I have a simple "language" that I'm using Flex(Lexical Analyzer), it's like this:
/* Just like UNIX wc */
%{
int chars = 0;
int words = 0;
int lines = 0;
%}
%%
[a-zA-Z]+ { words++; chars += strlen(yytext); }
\n { chars++; lines++; }
. { chars++; }
%%
int main()
{
yylex();
printf("%8d%8d%8d\n", lines, words, chars);
}
The I run a flex count.l, all goes ok without errors or warnings, then when I try to do a cc lex.yy.c I got this errors:
ubuntu#eeepc:~/Desktop$ cc lex.yy.c
/tmp/ccwwkhvq.o: In function yylex':
lex.yy.c:(.text+0x402): undefined reference toyywrap'
/tmp/ccwwkhvq.o: In function input':
lex.yy.c:(.text+0xe25): undefined reference toyywrap'
collect2: ld returned 1 exit status
What is wrong?
The scanner calls this function on end of file, so you can point it to another file and continue scanning its contents. If you don't need this, use
%option noyywrap
in the scanner specification.
Although disabling yywrap is certainly the best option, it may also be possible to link with -lfl to use the default yywrap() function in the library fl (i.e. libfl.a) provided by flex. Posix requires that library to be available with the linker flag -ll and the default OS X install only provides that name.
I prefer to define my own yywrap(). I'm compiling with C++, but the point should be obvious. If someone calls the compiler with multiple source files, I store them in a list or array, and then yywrap() is called at the end of each file to give you a chance to continue with a new file.
int yywrap() {
// open next reference or source file and start scanning
if((yyin = compiler->getNextFile()) != NULL) {
line = 0; // reset line counter for next source file
return 0;
}
return 1;
}
int yywrap(){return(1);}
use this code at the end of the program..Simple
flex doesn't always install with its development libraries (which is odd, as it is a development tool). Install the libraries, and life is better.
On Redhat base systems:
yum -y install flex-devel
./configure && make
On Debian based systems
sudo apt-get install libfl-dev
As a note for followers, flex 2.6.3 has a bug where libfl.a "typically would" define yywrap but then doesn't in certain instances, so check if that's your version of flex, might be related to your problem:
https://github.com/westes/flex/issues/154