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
Related
we're curruntly working on a C project and we've downloaded and used the header dirent.h, the problem is the code was compiled successfully on my teammate laptop but in mine it doesn't compile, telling me this :
In file included from utils.c:6:0:
dirent.h: In function '_wopendir':
dirent.h:383:28: error: missing binary operator before token "("
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
^
dirent.h:405:28: error: missing binary operator before token "("
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
^
dirent.h:413:5: warning: implicit declaration of function 'wcsncpy_s' [-Wimplicit-function-declaration]
wcsncpy_s (dirp->patt, n+1, dirname, n);
^
I searched for the problem and find that it's a preproccessor error and currently on the #if
i've tried to add #define WINAPI_FAMILY_PARTITION(Partitions) but it doesn't work.
Please suggest me a solution to compile it successfully, and does the windows version affect on preprocessing?
WINAPI_FAMILY_PARTITION is defined in <winapifamily.h>, probably included by <windows.h>. Look at this question for more explanations, but windows intricacies are largely irrelevant for your compilation issue. You might want include <windows.h> before <dirent.h>?
You did not publish the source code for your program, nor did you specify what OS you compile for not what compiler you use, but you mention we've downloaded and used the header dirent.h... This sounds wrong: system include files such as <dirent.h> are automatically installed with the compiler, they are specific to the OS and compiler, you cannot just download one from the net and expect it to work on your system. It might work by chance on your teammate's PC because the OS might be different.
I am trying to detect an error so I included in my program some traces.
The problem is that after that, it doesn't compile, giving me next error:
../src/DR700_API.c:46: parse error before `*'
I just added an fprintf at the beginning of each function:
fprintf(stdout,"_name_of_function_");
Commenting all fprintf it compiles right, so there's the error. I can't dispense with them as i want to track other error in execution time.
Here's a little example:
#include <stdio.h>
#include <stdlib.h>
ImprFunc *DR700_new()
{
fprintf(stdout,"DR700_new");
ImprFunc *impr = (ImprFunc *)malloc(sizeof(DR700_ImprFunc));
if (impr == NULL)
return NULL;
...
../src/DR700_API.c:46: parse error before `*'
../src/DR700_API.c:47: `impr' undeclared (first use in this function)
../src/DR700_API.c:47: (Each undeclared identifier is reported only once
../src/DR700_API.c:47: for each function it appears in.)
make: *** [../obj/DR700_API.o] Error 1
Probably your setup doesn't allow mixed code and declarations (as per C89). If you wish to not affect project setup - try to keep declarations before any code. In your example it means
ImprFunc *impr = (ImprFunc *)malloc(sizeof(DR700_ImprFunc));
fprintf(stdout,"DR700_new");
instead of
fprintf(stdout,"DR700_new");
ImprFunc *impr = (ImprFunc *)malloc(sizeof(DR700_ImprFunc));
Or alternatively - add -std=c99 (as was mentioned in comments).
In early versions of C, variables had to be declared at the beginning of a block.
C99 allows to mix declarations and statements arbitrarily (e.g. see Variable declaration placement in C and Where can I legally declare a variable in C99?).
You could try compiling with --std=c99 / --std=c11 which will allow you to declare variables anywhere (if supported in your version of gcc. See Status of C99 features in GCC and C11Status).
C99 is, for the most part, backward compatible with C89.
I am including two diferent lex parsers in my C code so to include the second one defined a Prefix on it:
%option prefix="prep"
When I integrated this one in the global proyect It compiles without errors but on execution, If I try to call prepparse (formerly yyparse) I get this error:
undefined symbol: prepparse
I have tried including an external reference (not quite sure if this is correct):
extern int prepparse(void);
And defining it in the Lex header:
#define yyparse prepparse
But I still get the same error.
Any idea of what I am doing wrong?
I think I got it. I have found I omited one information that has proben important. As I only wanted to alter some tokens and not defining a full language (it is only preparsing) I dind't define a Yacc file, so I was not actually a parser but a Lexer what I had to call. So the command is not preparse but preplex.
I stil don't have it working but I guess it is another different issue.
This is very puzzling to me because the code compiles without errors on a Debian 5 system but on a FreeBSD 7 I get a syntax error here on line 98 for example.
int ipmi_fru_get_board_info_mfg_time(ipmi_fru_t *fru, time_t *time);
Originally there was a line break between *fru, and time_t. Not sure what could cause these compiler errors but it felt important to mention the line break.
Or this one from line 298 left completely unaltered in its format.
int ipmi_fru_get(ipmi_fru_t *fru,
int index,
char **name,
int *num,
enum ipmi_fru_data_type_e *dtype,
int *intval,
time_t *time,
char **data,
unsigned int *data_len);
These are the unaltered errors output to terminal.
In file included from out_fru.c:37:
../include/OpenIPMI/ipmi_fru.h:98: error: expected declaration specifiers or '...' before 'time_t'
../include/OpenIPMI/ipmi_fru.h:298: error: expected declaration specifiers or '...' before 'time_t'
../include/OpenIPMI/ipmi_fru.h:474: error: expected declaration specifiers or '...' before 'time_t'
../include/OpenIPMI/ipmi_fru.h:559: error: expected declaration specifiers or '...' before 'time_t'
../include/OpenIPMI/ipmi_fru.h:627: error: expected declaration specifiers or '...' before 'time_t'
The subsequent errors seem to be related because they affect functions declared on the above lines of the ipmi_fru.h header file.
out_fru.c: In function 'ipmi_cmdlang_dump_fru_info':
out_fru.c:87: warning: passing argument 7 of 'ipmi_fru_get' from incompatible pointer type
out_fru.c:87: warning: passing argument 8 of 'ipmi_fru_get' from incompatible pointer type
out_fru.c:87: error: too many arguments to function 'ipmi_fru_get'
What could be causing these strange platform specific syntax errors? My first thought was some unprintable character but I've tried checking with cat -e include/OpenIPMI/ipmi_fru.h | less, all i see are spaces and line breaks.
In these types of cryptic errors, the best thing to do is run the preprocessor yourself and see what comes out. Sometimes a token is #defined somewhere in the headers and it becomes pretty much impossible to know what is going on.
In order to do it, find the compilation line for this .c file and run it as:
cpp <all -I switches from the compilation line> <all -D switches> yourfile.c outfile.tmp
Try to find the relevant line in outfile.tmp - it may look a little messy, but search for the original filename and linenumber - it shouldn't be too hard. When you find that line, hopefully it shouldn't be too hard to locate the actual problem.
Well you/original author must have included the file which includes the header where time_t is defined when compilation is successful. However you need to correctly find which is that file to know the correct solution to the problem.
You just cannot assume linux doesn't require you to include the file which shakes all fundamentals of programming :).
User Praveen answered my question well but just so I don't leave the thread unanswered I'll mention what I discovered.
The software seems to define its own time_t, either that or Linux does not require you to include time.h for the time_t data type.
Either way I managed to continue with my porting by simply including time.h on FreeBSD.
Im trying to compile z/lib on z/OS USS(thats right a mainframe). ive got gmake and the c89 compiler (which im assuming is c89 standards compliant) and USS is supposed to be POSIX compliant.
But zlib seems to be tripping up on
struct internal_state FAR *state; /* not visible by applications */
with the following error(s)
c89 -O3 -DUSE_MMAP -D_XOPEN_SOURCE_EXTENDED=1 -D_POSIX_SOURCE -c -o example.o example.c
ERROR CCN3277 ./zlib.h:92 Syntax error: possible missing ';' or ','?
ERROR CCN3007 ./zlib.h:92 "struct internal_state" is undefined.
ERROR CCN3166 ./zlib.h:103 Definition of function FAR requires parentheses.
ERROR CCN3276 ./zlib.h:103 Syntax error: possible missing '{'?
ERROR CCN3273 ./zlib.h:124 Missing type in declaration of gz_header.
ERROR CCN3166 ./zlib.h:126 Definition of function gz_header requires parentheses.
ERROR CCN3276 ./zlib.h:126 Syntax error: possible missing '{'?
WARNING CCN3137 ./zlib.h:1346 Declaration must declare at least one declarator, tag, or the members of an enumeration.
ERROR CCN3275 ./zlib.h:1350 Unexpected text z encountered.
ERROR CCN3282 ./zlib.h:1350 The type of the parameters must be specified in a prototype.
ERROR CCN3275 ./example.c:95 Unexpected text file encountered.
ERROR CCN3045 ./example.c:95 Undeclared identifier gzFile.
ERROR CCN3046 ./example.c:96 Syntax error.
ERROR CCN3045 ./example.c:98 Undeclared identifier file.
ERROR CCN3019 ./example.c:523 Expecting an array or a pointer to object type.
ERROR CCN3280 ./example.c:527 Function argument assignment between types "const char*" and "int" is not allowed.
CCN0793(I) Compilation failed for file ./example.c. Object file not created.
FSUM3065 The COMPILE step ended with return code 12.
FSUM3017 Could not compile example.c. Correct the errors and try again.
gmake: *** [example.o] Error 3
when i progressively take out the FAR * (i think its a far pointer but im really not that sure) the errors go away. But as this is a library, im not sure what other artifacts are going to be produced by removing this.
has anybody got any ideas?
any old mainframe heads out there?
it turns out there is a previous version of zlib that compiles on USS, version 1.1.4 or close to that. Its a back level, but i presume this works because it is before the implementation of the FAR pointer in the latest code. So atm i think ive got it to work.
thanks for all your help.
Regards
Mark.
FAR is not a C89 keyword, it is a Microsoft/Intelism and is probably #defined somewhere. If not, you need to define it as nothing:
#define FAR
However, this will probably only fix one of many problems. I would guess that the library uses some form of conditional compilation to handle things like FAR pointers - you need to read the docs to find which configuration is most suitabkle for your platform.
I'd use xlc instead of c89 since xlc is your system default compiler but you'll still probably have issues. I'd subscribe to the MVS-OE email list, the people on it are quite helpful. The link to info about the list appears to be down now so send email to
LISTSERV#VM.MARIST.EDU
with the message: INFO MVS-OE
FWIW, IBM provides a prebuilt version of zlib that includes support for the compression hardware (so-called zEDC) available on recent-vintage mainframes. See zlib for zEnterprise Data Compression