I'm trying to use SWIG to create a Octave function. But even the most basic example code seems to fail before I even get the chance to get it into octave. I am not sure if I should be concerned that swig creates a extension type for the C++ source file (.cxx) it generates that mkoctfile doesn't recognize (it only takes .C .cpp .cc, which seems like allot for swig to mess up that much and create what seems like the ONE extension for C++ it doesn't support).
Any help from someone with more experience with this would be greatly appreciated!
The steps I have done are as follows:
swig -octave swig_test.i
mv swig_test_wrap.cxx swig_test_wrap.cpp <--- This is necessary because mkoctfile doesn't recognize the cxx type c++ code that swig generates
mkoctfile swig_test_wrap.cpp
This results in 4 errors consistantly:
swig_test_wrap.cpp:1449:24: error: invalid covariant return type for 'virtual Octave_map octave_swig_type::map_value() const'
/usr/include/octave-3.4.0/octave/../octave/ov-base.h:560:22: error: overriding 'virtual octave_map octave_base_value::map_value() const'
swig_test_wrap.cpp:1657:24: error: invalid covariant return type for 'virtual Octave_map octave_swig_ref::map_value() const'
/usr/include/octave-3.4.0/octave/../octave/ov-base.h:560:22: error: overriding 'virtual octave_map octave_base_value::map_value() const'
The source code of my outlandishly basic swig_test.c
int fact(int n) {
if (n <= 1) return 1;
else return n*fact(n-1);
}
int my_mod(int x, int y) {
return (x%y);
}
Then the code of my wrapper inteface file swig_test.i
%module swig_test
%{
extern int fact(int n);
extern int my_mod(int x, int y);
%}
extern int fact(int n);
extern int my_mod(int x, int y);
___________________________________________________
UPDATE: May 9th 2011
So I still have not found a solution to this, and am starting to wonder if maybe these programs are out of date? The documentation most certainly is. Just as an example: the instructions say
swig -octave swig_test.i -o swig_test_wrap.cxx
now that will certainly not work regardless, because mkoctfile wont take type cxx as stated before. Also, this command just is physically written wrong. As typed above, it returns the error.
swig error : unrecognized option example.i
use swig -help for available options
The command SHOULD be entered as:
swig -octave -o swig_test_wrap.cpp swig_test.i
That WILL generate the swig_test_wrap.cpp file just as advertised. I would have thought there would be a -i option for input file in the argv of swig, but hey, now that I know that order matters here, someone must have just not updated the documentation when they changed something about how the function works.
So now, after running this command I have my swig_test_wrap.cpp file. Next I take that and try to execute
mkoctfile swig_test_wrap.cpp swig_test.c
Again, I get the same error as above: "invalid covariant return type" etc, however I also DO get a file swig_test.o out of the process. Just for fun, I then ran
mkoctfile swig_test.o
And lo and behold, this DOES generate a file called swig_test.oct. However when I went into octave and tried to load the file by running
octave:1>swig_test
I get the response error: 'swig_test' undefined near line 1 column 1
So as far as I can tell, I'm right back to square one. Anyone have any ideas?
So it turns out that this issue is related to the version of octave that I was using. Octave version 3.4.0 doesn't seem to work with swig yet. I got help on source-forge and once i downgraded to version 3.2.4-r3 it works perfectly.
And it is a known bug that you have to use:
swig -octave -o WRAPFILE.cpp INPUT.i
and its a problem with mkoctfile that you have to use the .cpp extension, since they SHOULD accept the .cxx extension as it is a valid extension for C++ files.
Try:
$ swig -octave -c++ swig_test.i -o swig_test_wrap.cxx
$ mkoctfile swig_test_wrap.cxx swig_test.c
as described here.
Related
I've added a new function wiringPiVersion() to wiringPi, but after I build and install the shared library, when I attempt to compile a small C program around it, I get:
wpi_ver.c:(.text+0xc): undefined reference to `wiringPiVersion'
However, when I include it in an XS based Perl module, all works well. I don't know enough about C to figure out what's going wrong here, and I've been searching for the better part of two hours trying different things to no avail.
Here's my small C program to test the new function:
#include <stdio.h>
#include <wiringPi.h>
int main (){
char * ver = wiringPiVersion();
printf("wiringPi version: %s\n", ver);
return 0;
}
Compilation that throws the error:
gcc -o ver wpi_ver.c -lwiringPi
The addition to wiringPi's header file:
extern char * wiringPiVersion(void);
The wiringPi's .c file addition:
#define WPI_VERSION "2.36"
char * wiringPiVersion(void){
return WPI_VERSION;
}
In my Perl module's XS file, I have:
char *
wiringPiVersion()
...and my Perl module's Makefile.PL
LIBS => ['-lwiringPi'],
...and after re-installing the Perl module, I can access the function without any issues in a test script.
I'm hoping this is something simple I'm overlooking which someone may be able to point out. My question is, how do I rectify this?
So it turned out that there were two .so files generated when I rebuilt wiringPi... one in the wiringPi's build directory way under my home directory, and the other in /usr/local/lib.
After a tip in comments, I added the library path explicitly:
gcc -o ver wpi_ver.c -L/usr/local/lib -lwiringPi
...and it all fell together and works as expected:
$ ./ver
wiringPi version: 2.36
Note: I have sent Gordon the patch in hopes it gets included in the next wiringPi cut.
Update: I received an email back from Gordon and he stated that currently, only the gpio application has the ability to report the version, so he advised that he's going to add something similar to my patch in a future release.
Although already solved, I added this answer to show what gave me the hint.
Error message "undefined reference" points to a linker error (cf. answer on SO), so its about checking if the correct library is drawn.
I am using MATLAB on the Linux MINT. I have a C program for which I want to used mex command as follows:
mex /home/.../binary.c -output binary_m
but I get the following error
Warning: You are using gcc version "4.8.1-10ubuntu9)". The version
currently supported with MEX is "4.4.6".
For a list of currently supported compilers see:
http://www.mathworks.com/support/compilers/current_release/
/home/.../binary.c:43:19: fatal error: binary.h: No such file or directory
#include "binary.h"
^
compilation terminated.
mex: compile of ' "/home/.../binary.c"' failed.
I think that I have to downgrade the gcc compiler on the MATLAB but I don't know how.
Any help is appreciate it.
Regards
This has nothing to do with the warning regarding the compiler version; don't pay attention to that, you will be fine. You might have had problems trying to compile c++11 sources, depending on your Matlab version, compiler version and mex command flags, but this is not your case.
Here is the problem: your C program binary.c contains an #include statement of the file binary.h which is not found by Matlab (although I trust you put it in the same directory than the C file?) because the directory that contains your C sources is not in the Matlab path.
To fix the problem, simply change directory to where binary.c is, and mex your file there. You can automate the process doing something like:
source_dir = '/home/.../';
current_dir = fileparts(mfilename('fullpath'));
cd source_dir;
% do something
cd current_dir;
I'm trying to update a project which uses SWIG to build an interface from ruby to matlab. The matlab C-API has changed and now I get the following error at runtime.
`mxCreateDoubleMatrix_730': Expected argument 0 of type mwSize, but got Fixnum 20 (TypeError)
I found mwSize defined in tmwtypes.h, which was not being included in the SWIG interface file:
tmwtypes.h:typedef int mwSize;
tmwtypes.h:typedef size_t mwSize; /* unsigned pointer-width integer */
But, if I add tmwtypes.h to the include section of the SWIG interface, I still get the TypeError and if I add it to both the include and the parse section, I get the following compile error:
Error: CPP #error ""This code must be compiled using a 2's complement representation for signed integer values"". Use the -cpperraswarn option to continue swig processing.
Giving up on tmwtypes.h, my solution is to add the following to the SWIG interface file.
%typemap(in) mwSize {
$1 = NUM2INT($input);
}
You can look at the complete SWIG interface file at:
https://github.com/morrifeldman/matlab-ruby/blob/master/ext/matlab_api/matlab_api.i
After adding this typemap, the program compiles and seems to work perfectly.
I have two related questions I would like answered:
Is the correct solution to the TypeError I am having with mwSize. Should I try something else instead?
I thought that including tmwtypes.h would fix my problem. Why didn't it work?
For reference, I'm using OSX Mountain Lion with Xcode 4.5.2. The Makefile is calling gcc-4.2. 'gcc-4.2 --version' gives 'i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1'
Thanks!
I was able to replace the typemap with:
typedef size_t mwSize;
However, I can't offer any insight into what is going on.
I have been following a tutorial to combine C with TCL using Swig. The tutorial seemed to be properly working but at the end I ran into an error that I cannot solve. The situation is as follows:
The tutorial I was following is:
http://www.swig.org/tutorial.html.
I have a file named test.c:
char *HelloWorld()
{
return "hello world";
}
and another named test.i:
%module test
%{
/* Put header files here or function declarations like below */
extern char *HelloWorld();
%}
extern char *HelloWorld();
I then used the following command line arguments to ready the correct files:
gcc -c test.c -o test.o
swig -tcl test.i
gcc -c test_wrap.c -o test_wrap.o
gcc -dynamiclib -framework Tcl test.o test_wrap.o -o test.so
And finally I tried to load it using:
tclsh
% load test.so test
This is the point where I received the following error:
dlsym(0x100600090, Test_Unload): symbol not founddlsym(0x100600090, Test_SafeUnload): symbol not found
As far as I know I did not stray from the tutorial. Can anyone tell me how it is that I got this error and more importantly how to get rid of it?
Thanks in advance!
Are those error messages stopping the load from working? They shouldn't; they're reporting that the low-level API for supporting unloading of the extension isn't present, but that's OK (lots of extensions can't be unloaded; it's tricky to write code that supports it).
You don't mention exactly which version of Tcl you are using — but it must be at least 8.5 for those symbols to be even searched for in the first place — so it is a little hard to guess what the exact underlying issue is. (The message should simply not be reported.) I advise filing a bug report on this; make sure you include all exact versions in your report.
It's a long time since I used SWIG, so I'm not sure whether it gives you sufficient control over the code it generates for you to be able to apply this fix. Glossing over that detail, I can reproduce (and fix) the issue with the following:
In 'ext.c':
#include <tcl.h>
int DLLEXPORT Ext_Init(Tcl_Interp *interp) {
if (Tcl_InitStubs(interp, TCL_VERSION, 0) == NULL) {
return TCL_ERROR;
}
if (Tcl_PkgProvide(interp, "Ext", "0.0") == TCL_ERROR) {
return TCL_ERROR;
}
return TCL_OK;
}
Build, run tclsh, load extension:
$ gcc -dynamiclib -framework Tcl ext.c -o ext.so
$ tclsh8.5
% load ./ext.so
dlsym(0x400000, Ext_SafeInit): symbol not found
dlsym(0x400000, Ext_Unload): symbol not found
dlsym(0x400000, Ext_SafeUnload): symbol not found
Something internal to the library loading code is putting that error message into the interpreters result. To stop the message ever surfacing, set or reset the result so that the _Init() function ends with one or other of:
// Set the result to a message of your choosing
Tcl_SetObjResult(interp, Tcl_NewStringObj("ok", -1));
// Or clear out the result altogether
Tcl_ResetResult(interp);
return TCL_OK;
}
The init block feature of swig might insert code in the right place to achieve the same thing:
%init %{
Tcl_ResetResult(interp);
%}
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.