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
Related
I have looked at similar question on this site and googled why this is happening but have tried these solutionnot able to compile, difference between ncurses and curses, another compile error, but I am still having the problem with the error undefined reference to stdscr and wgetch the compiler is finding the library as far as I can figure out as I used find to locate the curses library and entered the full location in the #include line.
my code is as follows
#include <ncurses.h>
#include <stdio.h>
#include <string.h>
int first_line(char);
int main(){
char c = 0;
while((c = getch())!=EOF){
first_line(c);
}
return 0;
}
int first_line(char c){
if (c != '\n' && c != '\r'){
putchar(c);
do{
c = getch();
putchar(c);}
while( c !='\n');
}
else return 0;
return 0;
}
If you can point to what I've missed or am doing wrong I would much appreciate it.
ncurses.h is a header file (containing declarations), not a library (containing code that implements those declarations).
The error message you're seeing is from the linker, not from the compiler.
If you're using gcc, you need to add either -lcurses or -lncurses to the compiler command line (after your source file name).
For example, on my system I copied your source to c.c, and I can compile and link it using either
gcc c.c -o c -lcurses
or
gcc c.c -o c -lncurses
UPDATED: Added complete example and compiler information
I have Eclipse 2019-03 (4.11.0) with CDT 9.7.0.20190309 and the build-in compiler reports false positive errors while using std::index_sequence in C++17:
#include <gtest/gtest.h>
#include <utility>
#include <array>
class Sample {
public:
template<std::size_t N >
std::size_t get_percentage( void ) {
return N;
}
template<std::size_t... Is>
inline std::array<std::size_t, sizeof...(Is)> calculate_percentages( std::index_sequence<Is...> ) noexcept {
return { this->get_percentage<Is>()... };
}
template<std::size_t N>
inline std::array<std::size_t, N> get_percentages( void ) noexcept {
return this->calculate_percentages( std::make_index_sequence<N>() );
/* ^^^^^^^^^^^^^^^^^^^^^ : Invalid arguments ' Candidates are: std::array calculate_percentages(std::integer_sequence) ' */
}
};
TEST( IntegerSequence, InvalidArgumentsError ) {
Sample test;
std::array<std::size_t, 5> data = test.get_percentages<5>();
for( int i = 0; i < 5; i++ ) {
std::cout << data[i] << std::endl;
}
}
int main( int argc, char ** argv ) {
testing::InitGoogleTest( &argc, argv );
return RUN_ALL_TESTS();
}
But the normal compilation succeeds without any problem.
My CDT GCC Built-in Compiler Settings in
Project Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers is as follows:
${COMMAND} ${FLAGS} -E -P -v -dD -std=c++17 "${INPUTS}"
The same applies for CDT Cross GCC Built-in Compiler Settings.
Rebuilding the index does not helped in there.
The GCC version I am using:
gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
Many thanks in advance to anyone willing to help...
The problem is caused by the fact that the standard library that comes with gcc 8 and newer uses a new compiler intrinsic called __integer_pack to implement std::make_integer_sequence (and related utilities like std::make_index_sequence).
Eclipse CDT's parser does not currently understand the __integer_pack intrinsic, and therefore it has trouble correctly parsing code that uses std::make_integer_sequence / std::make_index_sequence with these newer gcc versions.
I filed a CDT bug to track adding support for the __integer_pack intrinsic.
Meanwhile, a workaround you could employ is to use gcc 7 or older. If you need gcc 8 or newer to actually build your code, you could still tell Eclipse the look at the standard library headers of e.g. gcc 7 by replacing ${COMMAND} in the mentioned "built-in compiler settings" configuration with g++-7.
UPDATE: The Eclipse bug is now fixed, with the fix targeting CDT's 9.11 release (scheduled to be part Eclipse 2020-03).
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?
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 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.