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
Related
./theheader.h:349: Error: Syntax error in input(3).
Offending line:
string read_gdbm(GDBM_FILE dbf, string key_str, bool show_err = gbls.verbose);
Any ideas?
Typically, a syntax error in SWIG means that it can't understand the line in question (which can be annoying, because the line numbers don't follow macros such as %defines). So I suggest you check that string (should it be std::string? has it been defined?), GDBM_FILE (has it been defined? should it be in a namespace?) and maybe gbls.verbose (has it been defined?) make sense to SWIG. It may help to run swig with the -E option (be sure to redirect the stdout), find the corresponding line and search backward for each type involved. You may need to add some #includes.
Also check the previous line, to ensure you're not missing a semicolon, or something like that.
As a side note, I've run into the same issue for different reasons: I was trying to use a vector < vector < double >>. Now the ">>" character sequence mustn't be used with templates according to the C++99 standard, hence the swig error message popped up. The solution was to simply add an extra space to separate them.
I hit a similar error. I'll clarify my process, hope it can be helpful.
lib.i:
...
%begin %{
#include "header1.h"
%}
...
%include "header1.h"
header1.h:
19 typedef struct T {
...
23 } PACKED TlvHdr;
The error message just as below
./header1.h:23: Error: Syntax error in input(3).
I check the SWIG doc(http://www.swig.org/Doc1.3/SWIG.html 5.7.1) and found that the syntax error is so common, it's probably caused by a SWIG bug.
The doc recommended when encountering a syntax error to use #ifndef SWIG to omit statements that will make SWIG parser issue an error. So I changed the header1.h file, then the error disappeared.
header1.h:
#ifndef SWIG
19 typedef struct T {
...
23 } PACKED TlvHdr;
#endif
If you can't modify theheader.h file, you can make a new header file that just contains the declarations you need and replace the file from theheader.h to your new header file at %include directive
I had a similar issue and -E helped me understand that a macro definition was hidden inside an #ifndef SWIG block. I suspect that here it does not see the definition of GDBM_FILE, likely because it does not recurse.
I'm trying to install cgminer on OS X using MacPorts. It's been nothing but trouble since the start, but with the proper tools, common sense, and the Internet I've been able to get this far. Essentially, the compilation jams on sudo make install indicating a jam at line 956 of util.c - here is the text of the terminal output:
CC cgminer-cgminer.o
CC cgminer-util.o
util.c: In function ‘nanosleep_abstime’:
util.c:956: error: label at end of compound statement
make[1]: *** [cgminer-util.o] Error 1
make: *** [install-recursive] Error 1
And here is the contents of the cgminer copy of util.c opened in Xcode 4.6.3, cropped at nano sleep_abstime and with a comment inserted designating line 956:
static void nanosleep_abstime(struct timespec *ts_end)
{
uint64_t now_ns, end_ns, diff_ns;
struct timespec ts_diff;
struct timeval now;
end_ns = timespec_to_ns(ts_end);
gettimeofday(&now, NULL);
now_ns = timeval_to_ns(&now);
if (unlikely(now_ns >= end_ns))
goto out;
diff_ns = end_ns - now_ns;
ns_to_timespec(&ts_diff, diff_ns);
nanosleep(&ts_diff, NULL);
out:
#ifdef WIN32
timeEndPeriod(1);
#endif
} // LINE 956
#endif
Now, I'm not in any way, shape or form familiar with Unix/Linux commands or terminal in the least - I feel like a fish out of water, so everything I've learned I've had to learn by doing it wrong and then learning the hard way. However, I've read online that this error was solved by ending a label that was unresolved at the last portion of a function - that is, if the function ended at default:, a break; was placed between it and the end brace to resolve the error.
However, I have tried placing the break after the WIN32 #endif, inside the #ifdef preprocessor argument, and preceding it, directly after out:. All continue to fail the compiler. Any solutions for this? I feel like the solution is staring me in the face.
Here is relevant config/version information of my setup:
OS X 10.8.4 (12E55)
Xcode 4.6.3 w/ Command Line Tools installed
MacPorts version 2.2.0
It appears that this code has not been compiled on anything except Windows! Outside Windows, the #ifdef WIN32...#endif evaporates and, as you've seen, the label out: is left without a statement to label.
This is probably most clearly fixed by adding a null statement, explicitly for the non-Windows case:
out:
#ifdef WIN32
timeEndPeriod(1);
#else
;
#endif
}
(The two lines #else and ; have been added.)
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.
Hi I have several questions. I will be glad if someone will answer :)
I'm trying to compile linux driver for an lcd 16X2 module.
I'm trying to use in my code the struct file_operations();
1. I notice by other codes that they add #ifdef KERNEL21 to compile. I tryed to this and I got much less errors. why it's work this way. im using kernel 2.6.18-128.4.1.el5.. soo do I need to change to #ifdef KERNEL26? I get more errors if I try to do soo.
2.some of the file_operation arguments are function the rtuen ssize_t. what is this mean? in other code eample there is also "#ifdef KERNEL21" but still I get an error:
"lcd_module.c:74: error: expected identifier or ג(ג before ג{ג token"
3.last qustion, I worked with a Makfile example and I get .o file and not .ko that im use to work with. how do I run the module with the .o file?
thank on advance :)
ssize_t is basically a signed size_t and is widely used in the kernel because values less than zero are used to return errors in places where an unsigned size is expected. For example, the read file operation is expected to return the number of bytes read, but in case of insufficient memory you can return -ENOMEM and errno will be set appropriately in the user-space program.
With the 2.6 kernel you are supposed to use the Makefile from the kernel-headers package rather than a hand-crafted one, and it produces a .ko file rather than an .o. Further reading here: http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html
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.