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.
Related
I am currently tasked with getting code from one device to run on another and have a snippet of the functionality which means I need to shut down or feed the interfaces that are not being fed due to the cutting out of this module. When trying to compile I'm running into a syntax error that baffles me.
In a .h file I found a forward declaration at global scope like this:
void INT_CODE_ATTR fatal_error (unsigned char error_module, unsigned short error_line);
Where INT_CODE_ATTRwas not defined. Since I don't know what it could/should be I did this:
#define INT_CODE_ATTR
void INT_CODE_ATTR fatal_error (unsigned char error_module, unsigned short error_line);
This gave me the error:
error: declaration does not declare anything [-fpermissive]
So I changed ; to {} resulting in this error:
error: expected unqualified-id before '{' token
I thought it had to have something to do with INT_CODE_ATTR so I commented it out, but the error persists. Also the whole line is underlined (in Eclipse) and it tells me just: "Syntax Error".
Just to clarify, my last attempt at solving this looked like this:
#define INT_CODE_ATTR
void /*INT_CODE_ATTR*/ fatal_error (unsigned char error_module, unsigned short error_line) {}
The code sniplet you gave works just fine. Nothing wrong there (once you defined INT_CODE_ATTR).
Run gcc -E or your compilers equivalent to see what the pre-processor makes out of your actual code. What the actual compiler gets is not what you wrote, something is messing up the input.
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'm trying to cross compile my application for the maemo environment (GNU).
When compiling the application normally, everything works fine, however when it's compiled through sb2 the following warning comes up:
$ sb2 gcc -D_GNU_SORCE -o app -Wall -g -I.......//don't think this is relevant
In file included from wifi_collector_menu.c:50:
wifi_collector_list.c: In function `show_net_apns':
wifi_collector_list.c:777: warning: implicit declaration of function `getline'
I am completely confused as to why this happens, there are other getlines that do work in the program, i have tried to define the variable _GNU_SOURCE both inside the code and in the compiler command (not at the same time)
This is the line of code which causes the warning apparently:
size_t bytesnum = MAX_ESSID;
size_t bytes_read;
char *netname = NULL;
printf("Enter name of selected network:");
bytes_read=getline(&netname,&bytesnum,stdin);//This line
Any help would be appreciated, thanks in advance.
Problem solved, all I had to do was add:
#define _GNU_SOURCE
In each header file, before stdio.h was included, very simple really.
I guess this info is assumed known between programmers as i was unable to find it anywhere online, and had to ask my C programming professor personally, and even then we had some trouble tracing the source.
Thanks anyway.
Change your compiler line to include the -E option and redirect the output. The compiler will only pre-proccess your file when this option is used. Do this for both versions, with and without sb2. getline() is normally found in stdio.h. By viewing the preprocessed output from both versions, you should be able to see where getline() is being included from.
I have been trying to compile netcat.c on AIX for some time (using the command make aix), but the compiler gives me some weird feedback such as :
"netcat.c", line 117.12: 1506-275 (S) Unexpected text 'int' encountered.
when checked the file netcat.c at line 117, I would find the line (second line in code below):
#ifdef HAVE_BIND
extern int h_errno;
/* stolen almost wholesale from bsd herror.c */
even if I changed the int into char for the same of testing, save the file and re-run the command I get the same error
am I missing something in reading the error code?
If you're using xlc (especially older ones), it's normally caused by declarations after statements, something like:
i = i + 1;
int x;
You probably need to give us a little more context, such as 10 or so lines before the error line.
My advice would be to get gcc running on that box if you are using an older xlc. IBM makes some fine compilers now but the earlier ones weren't so crash hot (in my opinion).
When innocent-looking code produces bizarre errors, try running the code through the C preprocessor stage, and looking at it then. Sometimes macros do very funny things.
Also note that a problem on an earlier line (missing semicolon, etc.) might produce an error message on a later line.
The post maybe already a little outdated, but just in case someone else comes along with the same problem ...
Here (AIX 7.1) h_errno is defined as macro in netdb.h.
/usr/include/netdb.h:#define h_errno (*(int *)h_errno_which())
Therefore the declaration in netcat.c line 117 does not work.
I just changed the line into
#ifndef h_errno
extern int h_errno;
#endif
and the compilation worked smoothly.
#A.Rashad, I moved the HAVE_BIND #ifdef block from line 117 to line 30 which is just under the #include "generic.h" declaration. This permitted the xlc to compile it. The (S)yntax error messages are gone and while there are some (W)arning messages, I do get an nc binary at the end!
hth,
Kevin
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