tags:

views:

58

answers:

3

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.

+1  A: 

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.

adamk
A: 

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.

nocturnal
You should read the standard (POSIX) to determine which headers define `time_t` rather than simply relying on trial-and-error. Or rather, whoever wrote the original software should have done this...
R..
Yeah this porting process has mainly been researching headers and their availability between these two systems, right now i'm working with resolv.h. And no it is not my software, i'm just hoping to use it on FreeBSD eventually.
nocturnal
+1  A: 

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 :).

Praveen S
It is likely that some other system header is included which indirectly includes the header that defines `time_t` on Linux, but not on FreeBSD.
caf