Code in header files seems to cause errors on compile - c

I have a CLI program consisting of a single vt.c file that compiles and runs under Windows (cmd.exe) using Open Watcom. I can also compile it for Linux while running Open Watcom on Windows (and the resulting build runs under linux).
When I try to compile it under linux however (using make, which calls cc), I get 375 lines of error messages. Here are some of them, where many subsequent errors were similar, I have only pasted the first few:
In file included from vt.c:4:0:
process.h: In function ‘__declspec’:
process.h:45:22: error: storage class specified for parameter ‘execl’
process.h:46:1: error: expected declaration specifiers before ‘__declspec’
process.h:47:1: error: expected declaration specifiers before ‘__declspec’
...
In file included from vt.c:5:0:
ctype.h:48:1: warning: empty declaration
ctype.h:81:37: error: storage class specified for parameter ‘__ctype_b_loc’
ctype.h:82:6: warning: ‘__nothrow__’ attribute ignored
ctype.h:83:28: error: storage class specified for parameter ‘__ctype_tolower_loc’
ctype.h:84:6: warning: ‘__nothrow__’ attribute ignored
ctype.h:85:28: error: storage class specified for parameter ‘__ctype_toupper_loc’
ctype.h:86:6: warning: ‘__nothrow__’ attribute ignored
...
In file included from vt.c:6:0:
string.h:44:14: error: storage class specified for parameter ‘memcpy’
string.h:46:6: warning: ‘__nothrow__’ attribute ignored
string.h:49:14: error: storage class specified for parameter ‘memmove’
string.h:50:6: warning: ‘__nothrow__’ attribute ignored
string.h:57:14: error: storage class specified for parameter ‘memccpy’
string.h:59:6: warning: ‘__nothrow__’ attribute ignored
...
vt.c:28:1: warning: empty declaration
vt.c:41:1: warning: empty declaration
vt.c:50:1: error: parameter ‘maxtextlength’ is initialized
vt.c:70:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
vt.c:123:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
vt.c:158:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
...
vt.c:67:6: error: declaration for parameter ‘clearinputbuffer’ but no such parameter
vt.c:66:6: error: declaration for parameter ‘clrscr’ but no such parameter
vt.c:65:6: error: declaration for parameter ‘testrandom’ but no such parameter
...
string.h:579:14: error: declaration for parameter ‘stpncpy’ but no such parameter
...
ctype.h:268:12: error: declaration for parameter ‘toupper_l’ but no such parameter
...
process.h:45:22: error: declaration for parameter ‘execl’ but no such parameter
vt.c:608:1: error: expected ‘{’ at end of input
make: *** [vt] Error 1
My problem is, as (I'm sure) many have had before: I just want it to compile.
Question 3641178 seems to suggest that the order of the include files is important, but the headers that are giving errors come AFTER all other included files in vt.c.
I have tried installing Open Watcom on Linux, and the provided header files are the same. As far as I know, these are standard header files, and I can think of no reason why they should cause compile errors.
If anyone can shed any light on this, I'd be very grateful. The entire directory can be accessed in my git repo at git#github.com:megamasha/Vocab-Tester.git (https://github.com/megamasha/Vocab-Tester)

Your process.h, string.h, ... come from a specific compiler (watcom) and contain compiler-specific keywords (e.g. __declspec) that are not supported by gcc (the compiler usually used on Linux).
As far as string.h and ctype.h are concerned, you should remove them completely from your directory and #include them with angular brackets (<...>): they are standard headers and each compiler provide its versions (that are compatible with what the standard says).
With process.h, the situation is a bit more difficult, since it's a nonstandard header. Still, as far as I see, process.h seems to contain just some functions that are used to spawn processes, and, from a quick look, it seems that your application doesn't need it; if so, just remove process.h and the relative #include. Otherwise, tell me in the comment, probably there's a quick standard (or OS-specific, but not compiler-specific) replacement.

Related

C compiling error with shellforge

l made a C program and l want to compile it using shell forge but I had several errors, how can I solve them?
Errors
##[ERROR]## compiler reported error 1 while compiling /tmp/sfvLvXlY/sonu.c
##[ERROR]## In file included from :1:
././sflib/linux_amd64/sflib.h:93: warning: "struct rusage" declared inside parameter list
././sflib/linux_amd64/sflib.h:93: warning: its scope is only this definition or declaration, which is probably not what you want
././sflib/linux_amd64/sflib.h:97: warning: "struct sembuf" declared inside parameter list
In file included from /usr/include/stdio.h:34,
from /tmp/sfvLvXlY/sonu.c:3:
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/include/stddef.h:213: error: conflicting types for 'size_t'
././sflib/linux_amd64/../common/sftypes.h:25: error: previous declaration of 'size_t' was here

Compilation Error of C code on Linux (Same code compiles on OSX)

I am trying to compile some code on linux that I KNOW compiles on OSX, but I am getting some issues.
All of the files have headers named .h, and all of the files are in the same directory. I am compiling like this:
gcc *.c -std=c99 -lpthread
And while this code does compile on OSX, I get a bunch of weird linker errors on my Ubuntu install. Am I missing a few compiler options? It is a default Ubuntu-server install with the additional packages gcc and build-essential installed.
In file included from errorLogger.h:24:0,
from configParser.h:17,
from configParser.c:9:
signalHandling.h:24:18: error: unknown type name ‘sigset_t’
configParser.c: In function ‘parseConfigFile’:
configParser.c:114:5: warning: implicit declaration of function ‘getline’ [-Wimplicit-function-declaration]
In file included from errorLogger.h:24:0,
from global.h:18,
from connection.h:19,
from connection.c:10:
signalHandling.h:24:18: error: unknown type name ‘sigset_t’
connection.c: In function ‘createConnectionQueue’:
connection.c:189:28: warning: assignment makes integer from pointer without a cast [enabled by default]
In file included from errorLogger.h:24:0,
from database.h:16,
from database.c:9:
signalHandling.h:24:18: error: unknown type name ‘sigset_t’
In file included from errorLogger.h:24:0,
from errorLogger.c:10:
signalHandling.h:24:18: error: unknown type name ‘sigset_t’
errorLogger.c: In function ‘reportError’:
errorLogger.c:63:5: warning: implicit declaration of function ‘strerror_r’ [-Wimplicit-function-declaration]
errorLogger.c: In function ‘logMessage’:
errorLogger.c:87:5: warning: implicit declaration of function ‘localtime_r’ [-Wimplicit-function-declaration]
errorLogger.c: In function ‘processErrorQueue’:
errorLogger.c:131:17: warning: implicit declaration of function ‘open’ [-Wimplicit-function-declaration]
errorLogger.c:131:57: error: ‘O_APPEND’ undeclared (first use in this function)
errorLogger.c:131:57: note: each undeclared identifier is reported only once for each function it appears in
errorLogger.c:131:68: error: ‘O_CREAT’ undeclared (first use in this function)
errorLogger.c:131:78: error: ‘O_WRONLY’ undeclared (first use in this function)
errorLogger.c:131:88: error: ‘S_IWRITE’ undeclared (first use in this function)
errorLogger.c:131:99: error: ‘S_IREAD’ undeclared (first use in this function)
errorLogger.c:146:13: warning: implicit declaration of function ‘fsync’ [-Wimplicit-function-declaration]
errorLogger.c: In function ‘startErrorLogger’:
errorLogger.c:167:36: error: ‘O_APPEND’ undeclared (first use in this function)
errorLogger.c:167:47: error: ‘O_CREAT’ undeclared (first use in this function)
errorLogger.c:167:57: error: ‘O_WRONLY’ undeclared (first use in this function)
errorLogger.c:167:67: error: ‘S_IWRITE’ undeclared (first use in this function)
errorLogger.c:167:78: error: ‘S_IREAD’ undeclared (first use in this function)
errorLogger.c:214:57: error: ‘O_EXCL’ undeclared (first use in this function)
errorLogger.c:231:27: warning: assignment makes integer from pointer without a cast [enabled by default]
errorLogger.c: In function ‘closeErrorLogger’:
errorLogger.c:246:9: warning: implicit declaration of function ‘pthread_kill’ [-Wimplicit-function-declaration]
In file included from errorLogger.h:24:0,
from global.h:18,
from global.c:9:
signalHandling.h:24:18: error: unknown type name ‘sigset_t’
In file included from main.c:23:0:
signalHandling.h:24:18: error: unknown type name ‘sigset_t’
main.c: In function ‘main’:
main.c:53:5: warning: implicit declaration of function ‘blockSignals’ [-Wimplicit-function-declaration]
main.c:61:45: error: invalid application of ‘sizeof’ to incomplete type ‘struct addrinfo’
main.c:62:29: error: invalid application of ‘sizeof’ to incomplete type ‘struct addrinfo’
main.c:64:10: error: dereferencing pointer to incomplete type
main.c:65:10: error: dereferencing pointer to incomplete type
main.c:66:10: error: dereferencing pointer to incomplete type
main.c:66:23: error: ‘AI_PASSIVE’ undeclared (first use in this function)
main.c:66:23: note: each undeclared identifier is reported only once for each function it appears in
main.c:69:5: warning: implicit declaration of function ‘getaddrinfo’ [-Wimplicit-function-declaration]
main.c:73:9: warning: implicit declaration of function ‘gai_strerror’ [-Wimplicit-function-declaration]
main.c:73:9: warning: format ‘%s’ expects argument of type ‘char *’, but argument 4 has type ‘int’ [-Wformat]
main.c:73:9: warning: format ‘%s’ expects argument of type ‘char *’, but argument 4 has type ‘int’ [-Wformat]
main.c:81:41: error: dereferencing pointer to incomplete type
main.c:83:30: error: dereferencing pointer to incomplete type
main.c:83:46: error: dereferencing pointer to incomplete type
main.c:83:64: error: dereferencing pointer to incomplete type
main.c:96:30: error: dereferencing pointer to incomplete type
main.c:96:44: error: dereferencing pointer to incomplete type
main.c:112:5: warning: implicit declaration of function ‘freeaddrinfo’ [-Wimplicit-function-declaration]
main.c:138:9: error: unknown type name ‘fd_set’
main.c:142:9: warning: implicit declaration of function ‘FD_ZERO’ [-Wimplicit-function-declaration]
main.c:143:9: warning: implicit declaration of function ‘FD_SET’ [-Wimplicit-function-declaration]
main.c:145:9: warning: implicit declaration of function ‘pselect’ [-Wimplicit-function-declaration]
In file included from signalHandling.c:10:0:
signalHandling.h:24:18: error: unknown type name ‘sigset_t’
signalHandling.c:12:18: error: unknown type name ‘sigset_t’
signalHandling.c: In function ‘setHandler’:
signalHandling.c:51:53: error: invalid application of ‘sizeof’ to incomplete type ‘struct sigaction’
signalHandling.c:52:36: error: invalid application of ‘sizeof’ to incomplete type ‘struct sigaction’
signalHandling.c:54:5: warning: implicit declaration of function ‘sigemptyset’ [-Wimplicit-function-declaration]
signalHandling.c:54:30: error: dereferencing pointer to incomplete type
signalHandling.c:60:9: warning: implicit declaration of function ‘sigaddset’ [-Wimplicit-function-declaration]
signalHandling.c:60:35: error: dereferencing pointer to incomplete type
signalHandling.c:67:17: error: dereferencing pointer to incomplete type
signalHandling.c:72:9: warning: implicit declaration of function ‘sigaction’ [-Wimplicit-function-declaration]
You are probably missing some #includes which are brought in implicitly on OS X, but not on Linux.
Judging from the error messages, you are probably missing includes for at least:
<signal.h> (for sigset_t and others)
<fcntl.h> (for O_*)
<unistd.h> (for a bunch of stuff)
<netdb.h> (for various network functions and constants)
<stdio.h> (for getline)
You may also need to define some feature macros (e.g, _POSIX_C_SOURCE) to get certain system-dependent functions, including strerror_r and pselect.
I'm assuming that the immediate objective is to get the code to compile at all, and that once that's done, you'll go back and revise the source so it works out of the box on both platforms. That means that hacks are acceptable very short-term; they'll be fixed properly as you gain knowledge about what the portability issues are. (If it's any consolation, the first alternative system to the one where the software was originally developed is usually the hardest; after that, it generally gets easier.)
The first thing to try is:
gcc *.c -std=gnu99 -lpthread
This tells system header files to define many more symbols than -std=c99. (There's some dissent on this topic, which is OK. At the least, if you add -pedantic to a -std=c99 compilation, then symbols in standard C headers defined by POSIX are not exposed unless you also request POSIX support — see below. Since you don't have -pedantic, that may not be a factor in the compilations, in which case quietly move on to the next recommendation, which is the basis for future portability to POSIX systems.)
If that is insufficient to get you back on track, then you'll probably need to use something like:
gcc *.c -std=gnu99 -D_XOPEN_SOURCE=700 -lpthread
This says "Provide me with the POSIX and X/Open functions corresponding to POSIX 2008". You can try 600 and 500 for older versions, but you probably won't need to do so on Linux. In due course, you're likely to set _XOPEN_SOURCE automatically, either through a configuration header or via a configuration tool. While you're getting things to compile at all, specifying it on the command line is OK. In due course, you'll be using a makefile or equivalent to control the compilation and not typing a gcc command line at the shell.)
The sigset_t is defined in <signal.h> under POSIX. So, requesting POSIX support explicitly should get things to compile again properly. If you still get types such as sigset_t undeclared, then there must be a header on Mac OS X that includes the standard headers such as <signal.h> but which does some unrelated task on Linux (and therefore does not include <signal.h>). That will require source code scrutiny. However, it is relatively unlikely to be necessary.
You need to include additional header files because different system headers include other different system headers.
Also for example gcc has been working hard to not included headers that it should not.
Is signalHandling.h including #include <signal.h> where sigset_t is defined?
EDIT
After talking with the OP it seems the problems was a compile/link problem. Compiling the source into object files first and then linking them after seemed to have solved their problem.

troubles with implicit declaration static (compiling customized mupdf library)

I am compiling mupdf with a custom version of some functions in mupdf library. There are two functions that seem to call each other so when I create the _custom version of them an error is issued at compile time.
pc#pc:~/sviluppo/mupdf-0.9$ make
CC build/debug/obj_print.o
fitz/obj_print.c: In function ‘fmt_array_custom’:
fitz/obj_print.c:191:4: warning: implicit declaration of function ‘fmt_obj_custom’
fitz/obj_print.c: At top level:
fitz/obj_print.c:304:13: warning: conflicting types for ‘fmt_obj_custom’
fitz/obj_print.c:304:13: error: static declaration of ‘fmt_obj_custom’ follows non-static declaration
fitz/obj_print.c:191:4: note: previous implicit declaration of ‘fmt_obj_custom’ was here
make: *** [build/debug/obj_print.o] Errore 1
What's wrong? the default version of the functions already call each other the same way.
In line 191, the function fmt_array_custom is called without prior declaration. So the compiler implicitly assumes a declaration (non-static).
Later in line 304, it sees the actual function declaration/definition which is static. This is a conflict.
For fixing this you can add a declaration before line 191. Just copy the function proto-type (without the body) from line 304.

including tk.h and tcl.h in c program

i am working on an ubuntu system. My aim is to basically make an IDE in C language using GUI tools from TCL/TK. I installed tcl 8.4, tk8.4, tcl8.4-dev, tk8.4-dev and have the tk.h and tcl.h headers file in my system. But, when I am running a basic hello world program it's showing a hell lot of errors.
#include "tk.h"
#include "stdio.h"
void hello() {
puts("Hello C++/Tk!");
}
int main(int, char *argv[])
{ init(argv[0]);
button(".b") -text("Say Hello") -command(hello);
pack(".b") -padx(20) -pady(6);
}
Some of the errors are
tkDecls.h:644: error: expected declaration specifiers before ‘EXTERN’
/usr/include/libio.h:488: error: expected ‘)’ before ‘*’ token
In file included from tk.h:1559,
from new1.c:1:
tkDecls.h:1196: error: storage class specified for parameter ‘TkStubs’
tkDecls.h:1201: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
/usr/include/stdio.h:145: error: storage class specified for parameter ‘stdin’
tk.h:1273: error: declaration for parameter ‘Tk_PhotoHandle’ but no such parameter
Can anyone please tell me how can I rectify these errors? Please help...
This is not a valid program at all. What you are attempting to do is embed Tcl and Tk into your C application. Read the relevant sections in a Tcl/Tk book or research the Tcl Wiki (for instance 1).
To run Tcl or Tk commands you must have a Tcl_Interp properly initialized. So at minimum you must initialize the Tcl library and create an interpreter. Then for Tk you will need to initialize that library and run an event loop. The documentation for Tcl_AppInit discusses this and the tclAppInit.c file in the Tcl source (or tkAppInit.c in Tk) show you how to setup your app. Typically you would use the provided tkAppInit file as 'main' and put your custom application initialization into a Tcl_AppInit function that is called from the Tcl or Tk main function.
Calling Tk functions from C is ill advised. Define scripts and write the Tk bits in Tcl. Even Tk itself creates standard dialogs and such using Tcl scripts (from library/*.tcl).
but... shouldn't you use <> for systemwide include?! and button("..") -text("...") .. isn't good C grammar, unless tk.h gives powerful macros button and -text (which is problematic, i.e., not possible), and I suspect it is not so (in fact it is not so)...
You could be interested in this, and also a reading to this and digging around is worth; and also (more interesting for you maybe), read e.g. this

how to solve errors like ‘struct iphdr’ has no member named ‘daddr’

I ran a program ( the link is - http://www.security-freak.net/raw-sockets/sniffer_eth_ip_tcp.c ) in my fedora core 5. On compilation , i get the following errors :
[root#localhost ~]# gcc sniffer_eth_ip_tcp.c
In file included from sniffer_eth_ip_tcp.c:12: /usr/include/linux/ip.h:97: error: expected specifier-qualifier-list before ‘uint8_t’
In file included from /usr/include/linux/tcp.h:21,
from sniffer_eth_ip_tcp.c:13:
/usr/include/asm/byteorder.h:6:2: warning: #warning using private kernel header; include <endian.h> instead!
sniffer_eth_ip_tcp.c: In function ‘ParseIpHeader’:
sniffer_eth_ip_tcp.c:147: error: ‘struct iphdr’ has no member named ‘daddr’
sniffer_eth_ip_tcp.c:148: error: ‘struct iphdr’ has no member named ‘saddr’
sniffer_eth_ip_tcp.c: In function ‘ParseTcpHeader’:
sniffer_eth_ip_tcp.c:185: error: ‘struct iphdr’ has no member named ‘protocol’
sniffer_eth_ip_tcp.c:187: error: ‘struct iphdr’ has no member named ‘ihl’
But , the struct iphdr in the corresponding header file contains the above mentioned data members.
can anyone please help..
The only way to get that error is if the iphdr your program is referring to does not include those data members. So, search through all your includes, check for dup's, etc. (also, you can run the source through a precompile and find out EVERYTHING that has been included, that usually provides your answer)
[edit]
run cpp on your source to find out which header files are included (in which order). If you have a header with the wrong information included before the correct information, you will have a problem. In essence, only include the header files necessary to compile the program
[/edit]

Resources