I am trying to compile the project KernelGen (http://hpcforge.org/plugins/mediawiki/wiki/kernelgen/index.php/Compiling) for some research project I am doing , the build script is using rpmbuild and it looks like it has a dependency on gold from binutils. Build keeps failing when trying to compile gold with the following error:
/bin/sh ./../ylwrap yyscript.y y.tab.c yyscript.c y.tab.h yyscript.h y.output yyscript.output -- byacc -d
byacc: e - line 42 of "/home/xxx/rpmbuild/BUILD/binutils-2.23.2/gold/yyscript.y", syntax error
%pure-parser
^
The file yyscript.c looks like this:
/* We need to use a pure parser because we might be multi-threaded.
We pass some arguments through the parser to the lexer. */
%pure-parser
%parse-param {void* closure}
%lex-param {void* closure}
/* Since we require bison anyhow, we take advantage of it. */
%error-verbose
/* The values associated with tokens. */
It looks like it is some kind of grammar file that fails to parse. Things is this file is from the binutils package itself and I can't find a reason why it is failing to parse.
Any ideas ?
Your version of byacc doesn't properly support %pure-parser, which I believe was originally a bison extension. Use bison instead.
Related
i got this in my prog.ml:
#require "batteries";;
#require "Base";;
open Base;;
open Batteries;;
...
When I try to compile:
ocamlc prog.ml -o prg
it returns the following error:
1 | #require "batteries";;
^ Error: Syntax error
what is the correct command to compile the program?
Lines starting with #directive are meaningful only in the toplevel. They're not part of the actual syntax of OCaml. They just tell the toplevel to do various things that are useful during an interactive session.
If you're going to compile the code (rather than interacting with it in the toplevel), you just need to make sure the modules are accessible to the compiler. You can use a fancy build system, or you can use the -I flag that tells the compiler where to look for modules.
(You also have to remove the #directive lines from your source code, of course.)
I am attempting to build a project that comes with an automake/autoconf build system. This is a well-used project, so I'm skeptical about a problem with the configure scripts, makefiles, or code as I received them. It is likely some kind of environment, path, flag, etc problem - something on my end with simply running the right commands with the right parameters.
The configuration step seems to complete in a satisfactory way. When I run make, I'm shown a set of errors primarily of these types:
error: ‘TRUE’ undeclared here (not in a function)
error: ‘struct work’ has no member named ‘version’
error: expected ‘)’ before ‘PRIu64’
Let's focus on the last one, which I have spent time researching - and I suspect all the errors are related to missing definitions. Apparently the print-friendly extended definitions from the C standard library header file inttypes.h is not being found. However, in the configure step everything is claimed to be in order:
configure:4930: checking for inttypes.h
configure:4930: /usr/bin/x86_64-linux-gnu-gcc -c -g -O2 conftest.c >&5
configure:4930: $? = 0
configure:4930: result: yes
All the INTTYPES flags are set correctly if I look in confdefs.h, config.h, config.log Output Variables, etc:
HAVE_INTTYPES_H='1'
#define HAVE_INTTYPES_H 1
The problem is the same whether doing a native build, or cross-compiling (for arm-linux-gnueabihf, aka armhf).
The source .c file in question does have config.h included as you'd expect, which by my understanding via the m4 macros mechanic should be adding an
#include <inttypes.h>
line. Yes, as you may be inclined to ask, if I enter this line myself into the .c file it appears to work and the PRIu64 errors go away.
I'm left with wondering how to debug this type of problem - essentially, everything I am aware of tells me I've done the configure properly, but I'm left with a bogus make process. Aside from trying every ./configure tweak and trick I can find, I've started looking at the auto-generated Makefile.in itself, but nothing so far. Also looking into how I can get the C pre-processor to tell me which header files it's actually inserting.
EDIT: I've confirmed that the -DHAVE_CONFIG_H mechanic looks good through configure, config.log, Makefile, etc.
autoconf does not automatically produce #include directives. You need to do that on your own based on the HAVE_* macros. So you'll have to add something like this:
#ifdef HAVE_INTTYPES_H
# include <inttypes.h>
#endif
If these lines show up in confdefs.h, a temporary header file used by configure scripts, this does excuse your application from performing these #includes. If configure writes them to confdefs.h, this is solely for the benefit of other configure tests, and not for application use.
First, run make -n for the target that failed. This is probably some .o file; you may need some tweaking to get its path correctly.
Now you have the command used to compile your file. If you don't find the problem by meditating on this command, try to run it, adding the -E to force preprocessor output text instead of invoking the compiler.
Note that now the .o file will be text, and you must rebuild it without -E later.
You may find some preprocessor flags useful to get more details: -dM or -dD, or others.
Update: So turns out all I had to do to make bison generate t.tab.c was to use the -y switch. However, my original assumption of a problem with the code when the problem gave me a segfault seems correct according to the answers posted. Here is what it all looks like now:
The source is exactly the same as downloaded from the O'reilly website and I triple checked the ch1-04 code that this is based on. It's all extremely simple stuff. A program that recognises a sentence as a subject VERB and object Here is the code : ch1-05.l, ch1-05.y, ch1-05y.h
Original Question:
So succinctly I'm working my way to learning how to build a compiler.
I'm not very used to C\C++ and have never used lex and yacc before, this I'm following this book:
Now, in the book on page 21 this is what it says:
Now being on fedora 2 I don't have yacc. I installed bison.
Here is what the scene on my fedora looks like:
Do notice I am using -d.
If you'd really like to see the code here is : ch1-05.l, ch1-05.y, ch1-05y.h
I was actually silly enough and thought y.tab.c was an mistake in the book and they actually meant ch1-05.tab.c. I tried compiling with that and it gave me a segmentation fault :/ It took me a day to realize there is supposed to be a y.tab.c there.
I'm quite constantly checking SO so anything you need from me I will respond quick. I'd really like to get this done with because I'm on holiday due to a brain haemorrhage and I'd like to get this book complete soon. I have quite a list of books and quite a holiday :D
Thinking that bison would produce ch1-05.tab.c instead of y.tab.c wasn't silly at all, in fact that's what it did. Bison is GNU's version of Yacc, and though it is compatible with it in terms of grammar description, there are some differences in usage.
If you want to revert to conservative Yacc mode, try bison -y [...]:
-y
--yacc
--fixed-output-files
Equivalent to -o y.tab.c; the parser output file is called
y.tab.c, and the other outputs are called y.output and y.tab.h.
The purpose of this switch is to imitate yacc’s output file name
conventions. Thus, the following shell script can substitute
for yacc and is often installed as yacc:
bison -y "$#"
If you get a segfault running you program, it's more likely due to a programming error on your side. How did you link you binary ?
( ... some googling later ... )
Try this in ch1-05.y:
extern FILE *yyin;
main()
{
yyin = stdin; /* initialize yyin */
while(!feof(yyin)) {
yyparse();
}
}
The default output file name is one of the differences between yacc and bison. If you use bison -y then it will act more like yacc and produce a y.tab.c (and y.tab.h if -d is also used).
The -y option will just change the name of ch1-05.tab.c to y.tab.c, it won't solve the bug that caused your segfault.
I'm writing an implementation of the C preprocessor that, when running on Linux, needs to know the path on which to find header files. This can be obtained by running gcc -v. I want to compile the results into the binary of my preprocessor rather than having to invoke gcc -v on every run, so I'm currently thinking of writing a Python script to be run at compile time, that would obtain the path and write it into a small C source file to be included in the build.
On the other hand, I get the impression GNU Autotools is basically the specialist in obtaining system-specific information to be used at build time. Does Autotools have the ability to obtain the #include path in such a way that it can be incorporated as a string into the program being built (as opposed to being used for the build process)? If so, how?
If you want to get the internal include/ directory used by GCC, run the gcc -print-file-name=include command, e.g. in shell syntax
the_gcc_include_dir=$(gcc -print-file-name=include)
This $the_gcc_include_dirdirectory contains files like <stdarg.h> and <stddef.h> and many others.
You also want the include-fixed/ directory, so
the_gcc_include_fixed_dir=$(gcc -print-file-name=include-fixed)
This $the_gcc_include_fixed_dir contains files like <limits.h> and also a useful README
You probably don't need autotools in your case.
I ended up parsing gcc's include path with a Python script:
print 'string gcc_include_path[] = {'
for s in sys.stdin:
if s[0] == ' ':
s = s.strip()
print '\t"'+s+'",'
print '};'
and calling it from Makefile:
echo | cpp -Wp,-v 2>&1 >/dev/null | python include_path.py >include_path
As a part of my college project, we're supposed to develop a C compiler. The lexer and parser part is over - the tools Flex & Bison made our uphill task much simpler. Now where we're stuck is that we are unable to move on with the project. How exactly does one proceed once we have these three files in hand:
y.tab.h
y.tab.c
lex.yy.c
We also managed to produce an executable by using the following command on the DOS prompt
gcc lex.yy.c y.tab.c -o example1
and i got the executable example.exe...
Now how to proceed to get the compiler running? How to get it to build user C code?
You should check whether your example.exe can read a C program and report any syntax errors.
If it cannot, fix your .y and/or .l files and try again.
If it can, great, you have a working parser. Now turn it into a working compiler. Keep adding code, known as semantic actions, to the .y file, implementing more and more of the compiler's functionality. First, make sure you can report semantic errors, such as invalid types or missing declarations. Then implement assembly code generation.
When the .y file becomes too big, turn some code into functions and move them to separate .c files.