I am trying to compile gdb 9.2 in Ubuntu 18.04, The following errors are printed.
make[2]: Entering directory '/home/ata/gdb-9.2/build/gdb'
CXX ada-exp.o
ada-exp.y: In function ‘int ada_parse(parser_state*)’:
ada-exp.y:736:15: error: ‘yyin’ was not declared in this scope
ada-exp.y:736:15: note: suggested alternative: ‘yylen’
ada-exp.y:736:3: error: ‘lexer_init’ was not declared in this scope
ada-exp.y:736:3: note: suggested alternative: ‘pex_init’
In file included from ada-exp.y:56:0:
gdb 10.1 compiled successfully before this.
I searched online but could not come up with a reason or solution.
What might be the issue ?
Edit1: I have gcc version 7.5.0
I also faced this issue and this is how I fixed it:
ada-exp.y includes file ada-lex.c which contains the definition for function lexer_init.
But if you don't have flex installed initially, then it may generate an empty ada-lex.c (from ada-lex.l). And even if you do make clean, it will not clean the generated ada-lex.c, i.e., it will remain empty upon next compile command as well.
So to fix this error, you can delete all such intermediate .c files (in your case, building with fresh .tar.gz) and do the make again.
I want to use frama-c for static C code analysis. It already took me some effort to install it (hopefully) properly. The files are located at C:\CodeAnalysis\frama-c. I want to apply it via Windows console, e.g.:
C:\CodeAnalysis\frama-c\bin\frama-c hello.c
hello.c is just a simple hello-world-program (I am no C programmer btw and a newbie in programming)
#include <stdio.h>
main()
{
printf("Hello World \n");
}
So when running the above command there is the following output:
[kernel] preprocessing with "gcc -C -E -I. hello.c"
C:/Strawberry/c/x86_64-w64-mingw32/include/stdio.h:141:[kernel] user error: syntax error
[kernel] user error: skipping file "hello.c" that has errors.
[kernel] Frama-C aborted: invalid user input
Yes, I have Perl installed but have no idea why Frama uses it. To me it seems that there is somehow something wrong with the stdio.h. Can this be? But I can compile my program successfully.
C:\Strawberry\c\bin\gcc hello.c produces a nicely working exe file.
When removing the include statement from the file, there is the following output:
[kernel] preprocessing with "gcc -C -E I. hello.c"
hello.c:5:[kernel] warning: Calling undeclared function printf. Old style K&R code?
So frama itself does work and this is the kind of output I expected to have.
I also have MinGW installed and tried to make Frama use this for compiling. So I removed the Strawberry entries in my Windows Path. After that calling frama-c produces the same output.
When completely uninstalling Strawberry Perl, frama doesn't work (stating gcc is an unknown command), although C:\MinGW\mingw64\bin is also added to my Windows Path, even as very first entry.
C:\MinGW\mingw64\bin\gcc hello.c works, gcc hello.c doesn't.
When Perl is installed gcc hello.c works, even when I delete the Strawberry parts from the Windows Path variable. Wtf?
How can I make things work properly?
There are several issues here, and we have to isolate them in order to fix things.
Strawberry Perl installs its own gcc (based on MinGW), binutils, C headers, etc., by default on directory C:\Strawberry\c\bin. It adds this directory (among others) to the Windows Path variable. Frama-C expects gcc to be in the path, and it is Windows who decides which gcc to choose, if there are several directories in the path which contain a gcc binary. This is why Frama-C seems to use it.
One common mistake (not Windows-specific, but which happens more often in Windows due to the nature of its graphical applications) is to modify environment variables and forget to restart the processes which still have old copies of them (such as Command Prompt). echo %path% should confirm which directories are present in the path for the current command prompt, if there are any doubts about its value.
In case echo %path% contains the expected value, this is what might have happened (unfortunately I cannot reproduce your configuration to test it thoroughly): during installation of Frama-C, it may use the settings present during installation time to choose which directory contains gcc (in your case, C:\Strawberry\c\bin) and later hardcode this directory in its scripts.
This could explain why, after uninstalling Strawberry Perl, even if another gcc was in the path, it was not considered by Frama-C. Ideally, reinstalling Frama-C with a single gcc in the path could allow it to find the right version this time. Note that this is just a hypothesis, I may be completely wrong here.
In any case, the major problem you're having is not with gcc itself, but with the headers included with Strawberry Perl, as explained in the next item.
Concerning the error message:
C:/Strawberry/c/x86_64-w64-mingw32/include/stdio.h:141:[kernel] user error: syntax error
[kernel] user error: skipping file "hello.c" that has errors.
It is indeed not extremely informative and might change in future versions, but it does point to the source line which causes the error (file stdio.h, line 141):
int __cdecl __mingw_vsscanf (const char * __restrict__ _Str,
const char * __restrict__ Format,va_list argp);
In particular, it seems that __restrict__ is the source of the error here (Frama-C Sodium accepts restrict and __restrict, but not __restrict__; this may change in future versions).
Unfortunately, even fixing this (by adding e.g. #define __restrict__ restrict before #include <stdio.h> in your file) does not guarantee that the rest of the file will be parsed, since it seems to be a Windows-specific, C++-prone header that likely contains other C definitions/extensions that are not in the C99 standard, and possibly not accepted by Frama-C.
The best solution would be to ensure Frama-C uses its own stdio.h header, instead of Strawberry Perl's. It is usually installed in share/frama-c/libc (that is, it could be in C:\CodeAnalysis\frama-c\share\frama-c\libc in your installation), but depending on your configuration the headers might not have been found during execution, and Strawberry Perl's headers were included instead.
A quick hack for this specific case might be replacing:
#include <stdio.h>
with:
#include "C:\CodeAnalysis\frama-c\share\frama-c\libc\stdio.h"
But it is far from ideal and likely to lead to other errors.
If you manage to find out how to prevent Strawberry Perl's headers from being included, and ensure Frama-C's header files are included instead, you should be able to run Frama-C.
Note about Cygwin/MinGW path issues
I've had some issues when using a MinGW compiler and a Cygwin build (which is not necessarily a good idea), so here are some quick instructions on how to build Frama-C Sodium with a MinGW-based OCaml compiler using a Cygwin shell (but not a Cygwin-based OCaml compiler), in case it might help someone:
When running ./configure, you'll need to specify a --prefix using a Windows-based path instead of a Cygwin-based one, such as:
./configure --prefix="C:/CodeAnalysis/build"
If you don't, when running Frama-C (after make/make install) it will fail to find the libc/__fc_builtin_for_normalization.i file because it will try to use the Cygwin-based path, which will not work with the MinGW-based OCaml compiler.
Note that you cannot use backslashes (\) when specifying the prefix path, since they will not be correctly converted later.
I had to use the following command to ensure the makefile worked correctly:
make FRAMAC_TOP_SRCDIR="$(cygpath -a -m $PWD)"
Again, this is due to Cygwin paths not being recognized by the MinGW compiler (in particular, the absolute paths used by the plug-ins).
The previous steps are sufficient to compile and run Frama-C (plus the GUI, if you have lablgtk and other dependencies installed). However, there are still some issues, e.g. absolute Windows filenames are not always handled correctly. This can often be avoided by specifying the file names directly in the command line with relative paths (e.g. frama-c-gui -val hello.c), but in the general case, MinGW+Cygwin is not a very robust combination and other issues may arise.
Overall, mixing Cygwin and MinGW is not a good idea due to path issues, but it is nevertheless possible to compile and run Frama-C in such conditions.
Whilst attempting to make/compile the grafic package, I'm seeing this error after calling the make command within the grafic directory:
f77 -O2 -c grafic1.f
make: f77: No such file or directory
make: *** [grafic1.o] Error 1
I have XCode and all associated command line tools installed, what could be causing this error?
This error is make telling you that you have no binary in your path called f77. There are two things you need to look at the fix this:
Do you have a Fortran compiler installed? MacOS X/Xcode does not come pre-installed with one by default. The easiest options to install one are via third-party tools like macports or homebrew where you can install gfortran which may be a standalone package or may be part of the gcc package.
Once you have a compiler installed, your makefile needs to know about it. Without seeing the makefile this is only an assumption, but if autotools are not used the fortran compiler is usually hardcoded in a variable called FC, e.g. you might see a line
FC=f77
and you would change this to
FC=gfortran
assuming gfortran is in your path.
Once you have a Fortran compiler installed and the makefile knows about it, you should be able to execute make successfully.
Pantheios INSTALL.TXT says:
Open a command shell in the appropriate directory that matches your compiler: ...
My compiler is Clang:
> gcc --version
Apple LLVM version 5.1 (clang-503.0.40) ...
Target: x86_64-apple-darwin13.3.0
Which of the compiler settings files in Pantheios 1.0.1-beta214 is the most appropriate?
You can use homebrew to install an older version of gcc (e.g., gcc-4.2) and use the matching Pantheios makefile, like this:
brew install gcc42
make CC=gcc-4.2
However, as far as I have been able to tell, Pantheios is not going to be buildable on a recently-updated system. For example, as of today, building on OSX looks like this:
04:29:23 ~/src/pantheios-1.0.1-beta214/build/gcc42.unix$ make CC=gcc-4.2
Ensuring all STLSoft C source files are in UNIX format
sed: RE error: illegal byte sequence
make: *** [/Users/username/src/stlsoft-1.9.118/include/stlsoft/internal/dos2unix.has.been.performed] Error 1
I have also tried building on Windows as recently as 6 months ago and lost a good bit of time on it before giving up.
The library hasn't been updated in a very long time and the author has very little online activity since then. I call that "abandoned software". Building will very likely require a non-trivial amount of work on your part. I'd highly recommend severing the dependency on STLSoft if you do because it also appears to be abandoned.
I'm trying to compile pulseaudio on Mac OS X, however by default I get lots of errors about not finding standard files like inttypes.h, errno.h or stdio.h. Putting -isystem/usr/include in CPPFLAGS fixes those errors, but then later on I get fatal error: 'CoreServices/CoreServices.h' file not found.
I've tried also adding -framework CoreServices and/or
-I/System/Library/Frameworks/CoreServices.framework/Headers but neither work.
What's the proper way of making the compiler find it?
I think I'm using clang, gcc produces even more errors.
You are on the right track, those are the framework and include flags but if you use the correct configuration options you will find even the system includes are picked up properly.
The Makefiles will attempt to set the framework appropriately based on the --with-mac-sysroot and --with-mac-version-min attributes.
Example configuration option to specify the SDK location:
--with-mac-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/
--with-mac-version-min=10.7
If you are building on Mountain lion (10.8) you still need to use the 10.7 minimum compatibility as there are headers missing in the 10.8 SDK which PulseAudio makes reference to.
You can pass the configure options to the autogen.sh which will run configure once autoconf has completed. You can try the following command which has been tested on the master branch:
./autogen.sh --prefix=/usr/local --disable-jack --disable-hal --disable-bluez --disable-avahi --with-mac-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/ --with-mac-version-min=10.7 --disable-dbus
If you get m4 macro errors copy the m4 macros from aclocal into the m4 sub-directory and try again.
There are a few other problems but these are bound to be cleared up may date quickly. Adding it here as it may help someone trying to get this built.
error: Multiprocessing.h cannot be found:
This has been deprecated in 10.7 but the headers are still included it CoreServices and will build just change the include instruction in the file src/pulsecore/semaphore-osx.c.
-#include <Multiprocessing.h>
+#include <CoreServices/CoreServices.h>
error: ‘lt_PROGRAM_LTX_preloaded_symbols’ undeclared.
This may be a problem compiling src/daemon/dumpmodules.c and can be fixed by declaring the external macro.
extern const lt_dlsymlist lt_preloaded_symbols[];
error: gdbm.h: No such file or directory
For some reason the default include dir is not considered by the compiler and you can add the path to the src/Makefile look for and set the variable GDBM_CFLAGS.
GDBM_CFLAGS=-I/usr/local/include
nJoy!