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
Related
I compile my project with -Werror to make sure all of my code is without recognizable warnings. However my current project has a third-party dependency that has an issue in it which causes a warning - and that warning fails my build because of the -Werror flag.
I want to use the -Werror flag and I don't want to correct the third-party package. Is there a way to ignore this warning?
package.h:126:1: error: useless storage class specifier in empty declaration [-Werror]
};
The line of code that generates the error is a struct definition with a "dangling" typedef.
typedef struct my_data_obj {
char* data;
uint32_t data_size;
};
This is obviously a mistake - but I can't find any pragma or any such mechanic to ignore the warning generated from that header file. Any ideas?
EDIT: SOLUTION
Though I'm accepting Florian Weimer's answer because it answers the question most closely it's not the actual fix I settled with. I'll describe that bellow. By including the headers as system headers I did exactly what I wanted to do - suppress the error without having to fix the package.
What I finally did was create a patch file and simply apply that patch each time the project is built.
vim package.h
# fix the file
git add package.h
git diff --cached > package.h.patch
# on build time
git apply package.h.patch
I assume that you want to include package.h from files where you want to enable -Werror.
GCC does not have a separate flag to control this warning, otherwise the compiler would have printed it. With the separate flag, you could have used #pragma GCC diagnostics ignore, as indicated in the other answers, possibly with a wrapper header file.
However, you could put the header file into a separate directory, and instead of using -I to add it to the include path, use -isystem. As a result, the header file is treated as a system header, and unless you also compile with -Wsystem-headers, warnings in system headers are suppressed.
All warnings and errors have specific names, and can be enabled or disabled on a per-warning/-error basis.
For example lets say I have an unused variable and enabled warnings about it, then I will get a message similar to
/some/path/main.cpp:18:9: warning: unused variable ‘i’ [-Wunused-variable]
That last part of the message, the one inside the square brackets, is the name of the specific warning.
With this name you can then disable warnings using the -Wno-<name of warning> option. In the case of the above warning it's disabled with -Wno-unused-variable.
Your use-case is a little different in that you want to disable a warning turned into an error. This is very similar to the above, but the general form of the option is -Wno-error=<name of warning or error>. In our example case it's -Wno-error=unused-variable.
All of this is of course in the GCC documentation, more specifically in the warning options documentation.
So what you have to do is figure out the name of the warning, so you can use it for the -Wno-error= option.
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'm working in visual studio 2010 and I have code written in C.
If i run in 'Debug' mode, the code will run without any error or warning.
But if I run the same in 'Release' mode, errors and warning will appear.
Error List:
warning C4013:'fprintf' undefined; assuming extern returning int
error C2065: 'stdout': undeclared identifier
What is the reason? please help
warning C4013:'fprintf' undefined; assuming extern returning int
It looks like you didn't include stdio.h.
Seems like a difference in configuration between Release and Debug.
Check the values for "Whole Program Optimization", they may differ between the two build configurations.
I had the same problem in reverse: In Release mode everything was fine, but in Debug mode some functions like 'ext' (FFTW library) were reported as "undefined; assuming extern returning int".
The failing build configuration (Release in my case) had under project properties Configuration Properties > General the option "Whole Program Optimization" set to No Whole Program Optimization.
The successful build configuration had this set to Use Link Time Code Generation. When I set that option in my failing target as well, everything worked fine.
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.
I’m trying to initialize the Metal C environment with the following code, but get the following errors on the memset line.
ERROR CCN3275 IMIJWS0.METAL.SAMPLIB(MEM):6 Unexpected text ')' encountered.
ERROR CCN3045 IMIJWS0.METAL.SAMPLIB(MEM):6 Undeclared identifier ___MEMSET.
ERROR CCN3277 IMIJWS0.METAL.SAMPLIB(MEM):6 Syntax error: possible missing ')' or ','?
CCN0793(I) Compilation failed for file //'IMIJWS0.METAL.SAMPLIB(MEM)'. Object file not created.
Below is my code
#include < string.h>
#include < stdlib.h>
#include < metal.h>
void mymtlfcn(void) {
struct __csysenv_s mysysenv;
memset ( &mysysenv, 0, sizeof ( mysysenv ) );
mysysenv.__cseversion = __CSE_VERSION_1;
mysysenv.__csesubpool = 129;
mysysenv.__cseheap31initsize = 131072;
mysysenv.__cseheap31incrsize = 8192;
mysysenv.__cseheap64initsize = 20;
mysysenv.__cseheap64incrsize = 1;
The issue was with the search order. Although I did search(/usr/metal/include) from with in my JCL I didn't proceed it with a nosearch option, so string.h was getting picked up from the standard system librarys instead of the version included with Metal C. I've pasted my optfile dataset I passed to the CPARM below for refference.
//OPTIONS DD *
SO
LIST
LONG
NOXREF
CSECT
METAL
LP64
NOSEARCH
search(/usr/include/metal/)
So, I have no idea. But some suggestions:
You might try copying/pasting this code here from this example just to make sure it works 'as expected'
Maybe try defining some of the macros here? (when I did C programming on zOS, I had to do include some weird macros in order to get stuff to work. I have no reasonable technical explanation for this.)
You could try searching for memset() using "=3.14" (from ispf.) See if any other modules use that function, and then check the headers that they include (or macros that they define - either in the C files or H files) to make it work.
Another thought: before the memset(), try doing putting a printf() in. If you get a syntax error on the same line (only for printf, rather than memset) then you can see if the problem is before line 6 - like a misplaced parenthesis.
Finally, if i recall correctly, I had to compile my individual modules, and then link them manually (unless I wrote a JCL to do this for me.) So you might have to link once to link with your other modules, and then link again against the C library. Not to be pedantic, but: you're fairly certain that you're doing all of the link passes?
I realize that's a lot of hoops to try and you've probably already read the manuals, but maybe there is something useful to try?
Also, and you probably already know this, but this site (for looking up error codes) is infinitely useful. (along with the above links for full-text-searching the manual)
Edit: this page also talks about "built-in functions" - you could try (as stated at the bottom of the page) "#undef memcpy" to use the non-built-in version?
Can you show us your compiler arguments? You need to make sure that you're not pulling in the standard C header files in addition to the metal C ones. Here's an example:
xlc -c -Wc,metal,longname,nosearch,'list(./)' -I. -I /usr/include/metal -I "//'SYS1.SIEAHDRV'" -S -qlanglvl=extended foo.c
as -mrent -mgoff -a=foo.list -o foo.o foo.s
ld -bac=1 -brent -S "//'SYS1.CSSLIB'" -o foo foo.o
Are you missing the closing brace '}' for the function? How about any missing semi-colon line terminators? When missing braces/semi-colons the z/OS C compiler throws some strange/misleading messages sometimes. I don't have it to try out, but I'm assuming Metal does as well.