I am trying to switch my code to a new way of handling lexers in Scintilla.
This is what worked in previous versions of Scintilla, old ways:
scintilla_send_message(widget, SCI_SETLEXER, SCLEX_CPP, 0);
Since around version 4.4 I must do it new ways. From reading documentation I believe it is something like this:
ILexer5 *lexer = CreateLexer("cpp");
scintilla_send_message(widget, SCI_SETILEXER, 0, lexer);
But I am gettin ILexer5 is undefined and CreateLexer is undefined. I am tryng to find appropriate headers and static libs to add to my code and a compiler switch list. Please help.
My current GCC switches include this:
~/scintilla/bin/scintilla.a -DGTK -DSCI_LEXER -lstdc++ -I~/scintilla/include
Note I am using C not C++.
Lexilla.h is now in the lexilla repository.
As of February it has #ifdef __cplusplus guards, so it appears to support C as well.
If you still encounter issues, I'd suggest pasting the exact error message.
Related
I was compiling some 'C' code that uses openssl under Fedora 27 (version 1.1.0g-1). I made some needed changes (from the 1.0.2 version of my code) and things now compile o.k. again.
I then tried to compile with the option "OPENSSL_API_COMPAT=0x10100000L" which I understand causes the compiler to not include APIs deprecated in openssl version 1.1.
Now, my code won't compile and seems to not find the definitions of things like BN_bin2bn() and BN_free().
Looking at the headers, /usr/include/openssl/dh.h doesn't even include bn.h at all with this option set.
So, are the BN_xxxx functions now all deprecated in 1.1?
Looking at the openssl 1.1 documents in places like https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes doesn't mention this being the case.
The description of BN_bin2bn() at https://www.openssl.org/docs/man1.1.0/crypto/BN_bin2bn.html doesn't indicate this as deprecated as far as I can see.
Am I missing something? If these functions are deprecated, I would like to know what I'm supposed to use instead (for dh.h things, etc.).
Thanks;
.....c:927:8: error: implicit declaration of function ‘BN_bin2bn’; did you mean ‘OBJ_nid2sn’? [-Werror=implicit-function-declaration]
p = BN_bin2bn(dh1024_p, sizeof dh1024_p, NULL);
^~~~~~~~~
The BN functions are still present and non-deprecated. Check out the lack of relevant #ifs preceding line 180 in https://github.com/openssl/openssl/blob/OpenSSL_1_1_0-stable/include/openssl/bn.h
Looks like they must've just done some header-refactoring to eliminate header coupling. In fact, in the dh header for 1.1 we now see
# if OPENSSL_API_COMPAT < 0x10100000L
# include <openssl/bn.h>
# endif
at line 20 in https://github.com/openssl/openssl/blob/OpenSSL_1_1_0-stable/include/openssl/dh.h. So moving forward they don't include the bignum header automatically. This sounds exactly like improving the header coupling.
Try explicitly adding #include <openssl/bn.h> after your include of dh.h.
I am trying to compile some source codes about UNIX scokets programs, on Linux I have no problems but on macOS I get stuck in front of types definition problems. I don't know how many details I can put here, but I'll try.
The source codes to be compiled are:
errlib.c
errlib.h
server_test.c
sockwrap.c
sockwrap.h
where the main is located in server_test.c.
To compile I use:
gcc -Wall -DTRACE -o server_test server_test.c errlib.c sockwrap.c
There are no problems running this on Linux, but on macOS I get more than 20 error and all of these are about a (perhaphs) missing definition of bool_t. I suppose something not working in /usr/include/rpc/* files located in macOS internal libraries.
So I looked for if <sys/types.h> is included in /usr/include/rpc/xdr.h and it seems to be not missing.
Some of the first lines of the gcc output are:
In file included from server_test.c:16:
/usr/include/rpc/xdr.h:126:3: error: type name requires a specifier or qualifier
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:126:10: error: function cannot return function type 'int (struct __rpc_xdr *, int *)'
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:128:3: error: type name requires a specifier or qualifier
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:128:10: error: function cannot return function type 'int (struct __rpc_xdr *, const int *)'
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:128:3: error: duplicate member 'bool_t'
bool_t (*x_putlong)(struct __rpc_xdr *, const int *);
^
/usr/include/rpc/xdr.h:126:3: note: previous declaration is here
bool_t (*x_getlong)(struct __rpc_xdr *, int *);
^
/usr/include/rpc/xdr.h:136:3: error: type name requires a specifier or qualifier
bool_t (*x_getbytes)(struct __rpc_xdr *, char *, unsigned int);
...
and many others lines that are very similar.
For those who want to deepen, the sources are available here.
What could be the problem?
The bad answer
Issue solved by simply including <rpc/types.h> in the server_test.c source as follows:
#include <rpc/types.h>
The better one
This is a solution above is valid only for this server_test.c implementation.
If you want fix this issue "globally", you can follow follown steps:
disable SIP (how to? here)
get your macOS's xdr.h (from here /usr/include/rpc/xdr.h)
copy it elsewhere two times: one copy is for backup and modify the other one simply adding the required include (#include <rpc/types.h> and see the picture below)
overwrite your modified xdr.h onto the original one in /usr/include/rpc/
re-enable SIP
Here is how I did it:
In an attempt to add the include paths to Syntastic (3.6.0-106; Vim 7.3), to stop it from giving a fatal error at the first include it can't find, I tried creating a .syntastic_c_config file. There's not a lot of information on how this is supposed to work, but there are references out there and I followed their example:
-I/path/to/include
-I/you/get/the/idea
-L/some/library
-lfoo
-lbar
-DHAVE_SOME_FLAG
-pedantic
-Wall
-std=c99
That is, one compiler argument per line.
This has had the effect of removing virtually all error checking, unless I force it with :SynasticCheck -- at which point, it seems to work a little bit better, but not exactly how I'd expect. However, either way, if I :echo g:syntastic_c_config_file (or any other option that I'm expecting to be set), Vim just gives me an undefined variable warning.
I'm clearly doing something fundamentally wrong, but I'm not really sure what!
This is an old post, but I stumbled upon here searching for an answer to the same problem. Looks like Syntastic has changed quite a bit. Documentation listed above by OP is not valid anymore. Current (as of 18 July 2020) documentation is at: https://github.com/vim-syntastic/syntastic/blob/master/doc/syntastic-checkers.txt
To add include paths to 'gcc' checker, you would need to create a file with your include dirs, one per line, preceded by '-I'. For example, in /home/user/.syntastic_c_config_file add:
-I/usr/include/glib-2.0/include
-I/usr/include/boost
Then in your {vimrc} file (usually, ~/.vimrc), add one line:
let g:syntastic_c_config_file='/home/user/.syntastic_c_config_file'
Syntastic has become more powerful now and contains many options in the above linked documentation.
It turns out that Syntastic will source the configuration file without explicitly setting the respective variable. Moreover, the contents of the configuration file are not passed into any syntastic_c_* variables, but nonetheless passed into the call to gcc. Syntastic is also clever enough to backtrace to look for the configuration file (e.g., it will go up levels until it finds it, so you can keep the .syntastic_c_config in your project root).
As to why it was failing, the debug log was showing that my compiler was ignoring the library flags (-L/some/path and -lfoo) and that was blocking Syntastic from any further syntax checking. Removing those lines from my config file solved the problem.
I'm writing C code and was initially using the gcc checker. Errors were reported in the C file. Lots of errors that didn't matter were being reported due to, for instance, no include directory switches on the gcc command line in the checker. Because we're using icc and it feels unwieldy to setup all of the parameters that are already setup in our makefile, I decided to switch over to using the make checker.
Upon switching to the make checker, I did not get any results. Looking at the makeprg command in make.vim, it is make -sk. I realized that our makefile was not setup to do syntax checking, so I created a new target called syntax_check that added the -fsyntax-only and -c flags. I then changed the make.vim makeprg command to make -sk clean syntax-check so that the appropriate target is run.
When I save the file I watched top in another window and saw that the build is occuring. However, I'm still getting no errors. By this, I mean I don't see the green sidebar indicating lines that did not have errors. Running :Errors does not bring up the location list.
Any ideas? And is my understanding of how to look at the generated errors in syntastic wrong (which it may very well be)?
As a side note for the question here, I've also got this question in on the Syntastic github page here.
It turns out that the errorformat was wrong for handling icc. This, of course, makes total sense.
The errorformat for icc that I've got so far is:
let errorformat = '%W%f(%l): %tarning #%n: %m,%E%f(%l): %trror: %m'
I will add more to this as I find errors that aren't covered by this format or find that I need different formatting.
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.