swig / swig Goto Github PK
View Code? Open in Web Editor NEWSWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.
Home Page: http://www.swig.org
License: Other
SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages.
Home Page: http://www.swig.org
License: Other
SWIG (Simplified Wrapper and Interface Generator) Tagline: SWIG is a compiler that integrates C and C++ with languages including Perl, Python, Tcl, Ruby, PHP, Java, C#, D, Go, Lua, Octave, R, Scheme (Guile, MzScheme/Racket), Scilab, Ocaml. SWIG can also export its parse tree into XML. SWIG reads annotated C/C++ header files and creates wrapper code (glue code) in order to make the corresponding C/C++ libraries available to the listed languages, or to extend C/C++ programs with a scripting language. Up-to-date SWIG related information can be found at https://www.swig.org A SWIG FAQ and other hints can be found on the SWIG Wiki: https://github.com/swig/swig/wiki License ======= Please see the LICENSE file for details of the SWIG license. For further insight into the license including the license of SWIG's output code, please visit https://www.swig.org/legal.html Release Notes ============= Please see the CHANGES.current file for a detailed list of bug fixes and new features for the current release. The CHANGES file contains bug fixes and new features for older versions. A summary of changes in each release can be found in the RELEASENOTES file. Documentation ============= The Doc/Manual directory contains the most recent set of updated documentation for this release. The documentation is available in three different formats, each of which contains identical content. These format are, pdf (Doc/Manual/SWIGDocumentation.pdf), single page html (Doc/Manual/SWIGDocumentation.html) or multiple page html (other files in Doc/Manual). Please select your chosen format and copy/install to wherever takes your fancy. There is some technical developer documentation available in the Doc/Devel subdirectory. This is not necessarily up-to-date, but it has some information on SWIG internals. Documentation is also online at https://www.swig.org/doc.html. Backwards Compatibility ======================= The developers strive their best to preserve backwards compatibility between releases, but this is not always possible as the overriding aim is to provide the best wrapping experience. Where backwards compatibility is known to be broken, it is clearly marked as an incompatibility in the CHANGES and CHANGES.current files. See the documentation for details of the SWIG_VERSION preprocessor symbol if you have backward compatibility issues and need to use more than one version of SWIG. Installation ============ Please read the Doc/Manual/Preface.html#Preface_installation for full installation instructions for Windows, Unix and Mac OS X using the release tarball/zip file. The INSTALL file has generic build and installation instructions for Unix users. Users wishing to build and install code from Github should visit https://swig.org/svn.html to obtain the more detailed instructions required for building code obtained from Github - extra steps are required compared to building from the release tarball. Testing ======= The typical 'make -k check' can be performed on Unix operating systems. Please read Doc/Manual/Preface.html#Preface_testing for details. Examples ======== The Examples directory contains a variety of examples of using SWIG and it has some browsable documentation. Simply point your browser to the file "Example/index.html". The Examples directory also includes Visual C++ project 6 (.dsp) files for building some of the examples on Windows. Later versions of Visual Studio will convert these old style project files into a current solution file. Known Issues ============ There are minor known bugs, details of which are in the bug tracker, see https://www.swig.org/bugs.html. Troubleshooting =============== In order to operate correctly, SWIG relies upon a set of library files. If after building SWIG, you get error messages like this, $ swig foo.i :1. Unable to find 'swig.swg' :3. Unable to find 'tcl8.swg' it means that SWIG has either been incorrectly configured or installed. To fix this: 1. Make sure you remembered to do a 'make install' and that the installation actually worked. Make sure you have write permission on the install directory. 2. If that doesn't work, type 'swig -swiglib' to find out where SWIG thinks its library is located. 3. If the location is not where you expect, perhaps you supplied a bad option to configure. Use ./configure --prefix=pathname to set the SWIG install location. Also, make sure you don't include a shell escape character such as ~ when you specify the path. 4. The SWIG library can be changed by setting the SWIG_LIB environment variable. However, you really shouldn't have to do this. If you are having other troubles, you might look at the SWIG Wiki at https://github.com/swig/swig/wiki. Participate! ============ Please report any errors and submit patches (if possible)! We only have access to a limited variety of hardware (Linux, Solaris, OS-X, and Windows). All contributions help. If you would like to join the SWIG development team or contribute a language module to the distribution, please contact the swig-devel mailing list, details at https://www.swig.org/mail.html. -- The SWIG Maintainers
yodl2man version 2 and 3 do not seem to support the '-o' flag (at least on OS X).
Instead yodl2man creates a file called ccache.man
. Therefore make install will fail, because the created man file can not be found.
I created a patch that fixes this issue under OS X (attached below).
I did not issue a pull request, because the lines of Code seem to be with Swig since 2008 and I am not sure if the bug was never detected because the Makefile.in
is only part of the development version or because I am running this code on OS X.
diff -u a/CCache/Makefile.in b/CCache/Makefile.in
--- a/CCache/Makefile.in 2014-01-18 06:35:52.000000000 +0100
+++ b/CCache/Makefile.in 2014-01-18 06:43:42.000000000 +0100
@@ -28,27 +28,27 @@
all: $(PACKAGE_NAME)$(EXEEXT)
# Note that HTML documentation is actually generated and used from the main SWIG documentation Makefile
-docs: $(PACKAGE_NAME).1 web/ccache-man.html
+docs: ccache.man web/ccache-man.html
$(PACKAGE_NAME)$(EXEEXT): $(OBJS) $(HEADERS)
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(OBJS) $(LIBS)
-$(PACKAGE_NAME).1: ccache.yo
- -yodl2man -o $(PACKAGE_NAME).1 ccache.yo
+ccache.man: ccache.yo
+ yodl2man -o ccache.man ccache.yo
web/ccache-man.html: ccache.yo
yodl2html -o web/ccache-man.html ccache.yo
-install: $(PACKAGE_NAME)$(EXEEXT) $(PACKAGE_NAME).1
+install: $(PACKAGE_NAME)$(EXEEXT) ccache.man
@echo "Installing $(PACKAGE_NAME)"
@echo "Installing $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)"
${INSTALLCMD} -d $(DESTDIR)${bindir}
${INSTALLCMD} -m 755 $(PACKAGE_NAME)$(EXEEXT) $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
@echo "Installing $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1"
${INSTALLCMD} -d $(DESTDIR)${mandir}/man1
- ${INSTALLCMD} -m 644 ${srcdir}/$(PACKAGE_NAME).1 $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
+ ${INSTALLCMD} -m 644 ${srcdir}/ccache.man $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
-uninstall: $(PACKAGE_NAME)$(EXEEXT) $(PACKAGE_NAME).1
+uninstall: $(PACKAGE_NAME)$(EXEEXT) ccache.man
rm -f $(DESTDIR)${bindir}/`echo $(PACKAGE_NAME) | sed '$(transform)'`$(EXEEXT)
rm -f $(DESTDIR)${mandir}/man1/`echo $(PACKAGE_NAME) | sed '$(transform)'`.1
@@ -67,7 +67,7 @@
/bin/rm -rf autom4te.cache
maintainer-clean: distclean
- /bin/rm -f $(PACKAGE_NAME).1 web/ccache-man.html
+ /bin/rm -f ccache.man web/ccache-man.html
# FIXME: To fix this, test.sh needs to be able to take ccache from the
SWIG autogenerates a swig_import_helper()
Python function, which from what I can see, attempts to do relative imports in a way that remains valid syntax in Python 2.4. Unfortunately, the use of __file__
doesn't work in frozen applications, and it falls back to import %s
(line), which doesn't work as a relative import in Python 3.
If I change the line to from . import %s
, it works again. I guess that is invalid syntax on Python 2.4, but I don't have such an old version of Python handy to test. Projects that work on Python 3 rarely support Python 2.4, so it may be practical to make this an option.
This was reported as a bug with cx_Freeze, a Python freezing tool, but I don't see a good way to fix it in cx_Freeze, so I wanted to bring it up here.
Imagine you put a typemap like this:
typemap(out) Namespace::A "Example";
Added to this Namespace::A is a typedef to Namespace::B
namespace Namespace {
typedef B A;
}
now use a vector of Namespace::A
%template(Namespace::A) std::vector<Namespace::A>;
There is an problem! For example in python for getitem function it will try the following typemap:
std::vector< Namespace::B >::value_type
then
Namespace::B
A correct behaviour should be
std::vector< Namespace::A >::value_type
Namespace::A
std::vector< Namespace::B >::value_type
Namespace::B
or
std::vector< Namespace::A >::value_type
std::vector< Namespace::B >::value_type
Namespace::A
Namespace::B
Hello,
It would be quite nice if Swig could manager PHP namespaces.
Il is quite similar to the java namespacing.
Thank you !
In c/c++, a default copy ctor is created for all structs/classes. In case of simple (POD?) types, it resolves into a one-line memcpy, which is fine as long as we dont have pointers etc. that needs deepcopy.
However on the Java side (which is what I work with right now), this default copy ctor is not automatically reflected (understantably). This forces me to wrap all my (many!) POD structs in a template class that explictly implements a copy ctor, to be able to have them in Java.
It would be cool in someway to be able to tell Swig to generate a simple default copy ctor without having to write the code manually in the .i file.
To achieve this, I was thinking using the std::is_pod defined in c++11, and skip it on older compilers. Would be glad to contribute.
I'm following the user guide to code a Matlab module for SWIG.
In the section "39.10.6 Module I/O and wrapper skeleton", the line "Close(f_begin);" causes the following error message:
Modules/matlab.cxx:268:5: error: use of undeclared identifier 'DohClose'
Close(f_begin);
^
../Source/DOH/doh.h:427:28: note: expanded from macro 'Close'
#define Close DohClose
The two tests template_using_directive_and_declaration_forward and using_directive_and_declaration_forward fail to build in the java test suite. The code and errors are shown below. This is for clang-500 on mavericks and clang-425 on mountain lion.
This seems to be a clang issue - this code builds fine on g++ 4.2 and 4.8. li_std_vector also has a build failure.
214: namespace Outer1 {
215: namespace Space1 {
216: template<typename T> class Thing1;
217: }
218: }
219: using namespace Outer1::Space1;
220: using Outer1::Space1::Thing1;
221: template<typename T> class Thing1 {};
222: void useit1(Thing1<int> t) {}
clang++ -c -I/opt/local/include template_using_directive_and_declaration_forward_wrap.cxx -I../../../../Examples/test-suite -I"/System/Library/Frameworks/JavaVM.framework/Headers" -I"/System/Library/Frameworks/JavaVM.framework/Headers"
template_using_directive_and_declaration_forward_wrap.cxx:222:6: error: variable has incomplete type 'void'
void useit1(Thing1 t) {}
^
template_using_directive_and_declaration_forward_wrap.cxx:222:13: error: reference to 'Thing1' is ambiguous
void useit1(Thing1 t) {}
^
template_using_directive_and_declaration_forward_wrap.cxx:220:23: note: candidate found by name lookup is 'Thing1'
using Outer1::Space1::Thing1;
^
template_using_directive_and_declaration_forward_wrap.cxx:221:28: note: candidate found by name lookup is 'Thing1'
template class Thing1 {};
^
From their style guide: http://golang.org/doc/effective_go.html#Getters
Go doesn't provide automatic support for getters and setters. There's nothing wrong with providing getters and setters yourself, and it's often appropriate to do so, but it's neither idiomatic nor necessary to put Get into the getter's name. If you have a field called owner (lower case, unexported), the getter method should be called Owner (upper case, exported), not GetOwner. The use of upper-case names for export provides the hook to discriminate the field from the method. A setter function, if needed, will ikely be called SetOwner. Both names read well in practice:
There is a severe bug regarding thread savity in the functions
SWIG_TypeCheckStruct and SWIG_TypeCheck, that did cost me quite some time to figure out. I propose to generally apply the following bugfix, so others do not run into this too.
The commented code below in these functions is not thread safe, as the swig_type_info structures are static. So using for example multiple Lua States, running on different threads results in hard to find and reproduce, mind blowing, random errors and all kinds of strange misbehaviour...
The function is at least used commonly in the generated wrapper functions for Lua.
And I guess it is also used for all the other languages as well, but I have not checked this. So I guess without this bugfix, probalbly all language wrappers are NOT thread safe without the following fix:
/*
Check the typename
*/
SWIGRUNTIME swig_cast_info *
SWIG_TypeCheck(const char *c, swig_type_info *ty) {
if (ty) {
swig_cast_info *iter = ty->cast;
while (iter) {
if (strcmp(iter->type->name, c) == 0) {
if (iter == ty->cast)
return iter;
/*
THREAD SAVITY BUGFIX. See also SWIG_TypeCheckStruct
Move iter to the top of the linked list
iter->prev->next = iter->next;
if (iter->next)
iter->next->prev = iter->prev;
iter->next = ty->cast;
iter->prev = 0;
if (ty->cast) ty->cast->prev = iter;
ty->cast = iter;
*/
return iter;
}
iter = iter->next;
}
}
return 0;
}
/*
Identical to SWIG_TypeCheck, except strcmp is replaced with a pointer comparison
*/
SWIGRUNTIME swig_cast_info *
SWIG_TypeCheckStruct(swig_type_info *from, swig_type_info *ty) {
if (ty) {
swig_cast_info *iter = ty->cast;
while (iter) {
if (iter->type == from) {
if (iter == ty->cast)
return iter;
/*
THREAD SAVITY BUGFIX.
Move iter to the top of the linked list
iter->prev->next = iter->next;
if (iter->next)
iter->next->prev = iter->prev;
iter->next = ty->cast;
iter->prev = 0;
if (ty->cast) ty->cast->prev = iter;
ty->cast = iter;
*/
return iter;
}
iter = iter->next;
}
}
return 0;
}
Alternate solutions:
Array with more than two dimensions, e.g. extern double x[2][3][4];
lead to wrapped code with compile errors:
swig_wrap.c: In function ‘_wrap_x_set’:
swig_wrap.c:2425:50: error: incompatible types when assigning to type ‘double[4]’ from type ‘double’
for (; jj < (size_t)3; ++jj) x[ii][jj] = inp[ii][jj];
^
Hey guys, sorry for the mistake when submitting.
I'm trying to build Go bindings for C++ lib, and while it does work on Linux, Mac, here are the steps I have to do to modify the cxx
file to make it work on Windows, based in part on https://groups.google.com/forum/#!topic/golang-nuts/9L0U4Q7AtyE
First of all, change all struct swigargs
to be __attribute__((__packed__))
, according to https://code.google.com/p/go/source/browse/src/cmd/cgo/out.go#530 :
$ sed -i '' 's/} \*swig_a/} __attribute__((__packed__)) \*swig_a/g' file_wrap.cxx
For instance
struct swigargs {
long : 0;
intgo result;
} __attribute__((__packed__)) *swig_a = (struct swigargs *) swig_v;
However, on Win32, long long int
is broken, suggested fix is, according to https://code.google.com/p/go/issues/detail?id=6541 :
$ sed -i '' 's/__attribute__((__packed__))/__attribute__((__packed__, __gcc_struct__))/g' file_wrap.cxx
struct swigargs {
long : 0;
intgo result;
} __attribute__((__packed__, __gcc_struct__)) *swig_a = (struct swigargs *) swig_v;
Also, Windows doesn't resolve symbols at compile time, so we need to properly set these symbols in a DllMain
, and then have the file use them, see the dllmain file here: https://gist.github.com/steeve/7152742/raw/dllmain.cxx
Finally, we need to fix the imports, I do it like so:
# Comment out externs
sed -i '' 's/\(extern void\)/\/\/\1/' $@
# Insert dllmain
cat dllmain.i $@ > [email protected]
mv [email protected] $@
# Fix imports by specifying then to the external dll, and commenting the x_wrap_* symbols
sed -i '' 's/\(#pragma dynimport _ _\)/\/\/\1/' libtorrent_gc.c
sed -i '' 's/\(#pragma dynimport.*\)\(""\)/\1"$(LIBRARY_NAME)"/g' libtorrent_gc.c
sed -i '' 's/\(static void (\*x_wrap_\)/\/\/\1/g' libtorrent_gc.c
sed -i '' 's/cgocall(x\(_wrap_.*\)/cgocall(\1/g' libtorrent_gc.c
And here is a snippet of my Makefile to do that:
$(SRCS) $(GOFILES): $(SWIG_FILES)
$(SWIG) $(SWIG_FLAGS) -o $@ -outdir . $<
# It should always be like this, according to https://code.google.com/p/go/source/browse/src/cmd/cgo/out.go
sed -i '' 's/} \*swig_a/} __attribute__((__packed__)) \*swig_a/g' $@
# Temp fix for https://code.google.com/p/go/issues/detail?id=6541
# See also https://code.google.com/p/go/issues/detail?id=5603
ifeq ($(CC), gcc)
ifneq (,$(filter $(ARCH),x86 x64))
sed -i '' 's/__attribute__((__packed__))/__attribute__((__packed__, __gcc_struct__))/g' $@
endif
endif
ifeq ($(OS), Windows_NT)
# Patch SWIG generated files for succesful compilation on Windows.
# Based on https://groups.google.com/forum/#!topic/golang-nuts/9L0U4Q7AtyE
# Comment out externs
sed -i '' 's/\(extern void\)/\/\/\1/' $@
# Insert dllmain
cat dllmain.i $@ > [email protected]
mv [email protected] $@
# Fix imports by specifying then to the external dll, and commenting the x_wrap_* symbols
sed -i '' 's/\(#pragma dynimport _ _\)/\/\/\1/' libtorrent_gc.c
sed -i '' 's/\(#pragma dynimport.*\)\(""\)/\1"$(LIBRARY_NAME)"/g' libtorrent_gc.c
sed -i '' 's/\(static void (\*x_wrap_\)/\/\/\1/g' libtorrent_gc.c
sed -i '' 's/cgocall(x\(_wrap_.*\)/cgocall(\1/g' libtorrent_gc.c
endif
See the debugging output below, the lookup for 'char const [ANY]' is skipped, among others, in the case that a typedef as defined below is used. (in swig 2.0.9)
typedef char A_string[128 + 8];
Searching for a suitable 'default' typemap for: char const prefix[20+1]
Looking for: char const prefix[20+1]
Looking for: char const [20+1]
Looking for: char const prefix[ANY]
Looking for: char const [ANY]
Looking for: char prefix[20+1]
Looking for: char [20+1]
Looking for: char prefix[ANY]
Looking for: char [ANY]
Looking for: SWIGTYPE const prefix[ANY]
Looking for: SWIGTYPE const [ANY]
Looking for: SWIGTYPE prefix[ANY]
Looking for: SWIGTYPE [ANY]
Looking for: SWIGTYPE prefix[]
Looking for: SWIGTYPE []
Looking for: SWIGTYPE *prefix
Looking for: SWIGTYPE *
Looking for: SWIGTYPE prefix
Looking for: SWIGTYPE
None found
Searching for a suitable 'default' typemap for: A_string const device_name
Looking for: A_string const device_name
Looking for: A_string const
Looking for: A_string device_name
Looking for: A_string
Looking for: char const device_name[128+8]
Looking for: char const [128+8]
Looking for: char device_name[128+8]
Looking for: char [128+8]
Looking for: char device_name[ANY]
Looking for: char [ANY]
Looking for: SWIGTYPE const device_name[ANY]
Looking for: SWIGTYPE const [ANY]
Looking for: SWIGTYPE const device_name[]
Looking for: SWIGTYPE const []
Looking for: SWIGTYPE *const device_name
Looking for: SWIGTYPE *const
Looking for: SWIGTYPE const device_name
Looking for: SWIGTYPE const
Looking for: SWIGTYPE device_name
Looking for: SWIGTYPE
None found
SWIG misparses a method name in parentheses, which is sometimes used to avoid macro expansion (if there was a foo macro taking one argument in this case):
%module misparse
%inline %{
struct Foo {
int (foo)(int i);
};
%}
With current trunk:
$ ./preinst-swig -c++ -python misparse.i
misparse.i:3: Warning 504: Function Foo::int(foo) must have a return type. Ignored.
I believe this is valid C++ - GCC and clang are both happy with it.
I've not dug into the parser to try to work out what's happening.
Creating a director wrapper for classes with methods marked as const:
class Base {
protected:
virtual bool GetBoolean() const = 0;
}
results in an incorrect "wrap:action" in the wrapped method call. The cast is inserted as (memberfunctionHandler:value const *)darg
and it should be (SwigDirector_Base const *)darg
.
I tracked this down to DirectorClassName
being incorrect at https://github.com/swig/swig/blob/master/Source/Modules/lang.cxx#L1253. I'm not sure how DirectorClassName should be set properly, but I was able to resolve the code generation by calling directorClassName with the methods parent node by changing:
director_type = Copy(DirectorClassName);
to:
director_type = Copy(directorClassName(Getattr(n, "parentNode")));
I am using the parent node because the method node does not have an appropriate "nspace" parameter and will not generate a correct value when using namespaces. Also, this may only be happening for protected methods, but I'm not sure.
I have just cloned swig on the master branch to be sure to have the latest version and I've built it from source. It says:
$ swig -version
SWIG Version 2.0.11
I am trying to create a (detailed) SWIG interface (for PHP) for libssl:
$ openssl version
OpenSSL 1.0.1c 10 May 2012
I am mostly interested in using the functions listed in:
The problem is that I am getting syntax errors all over the place:
/usr/include/openssl/asn1.h:556: Error: Syntax error in input(1).
GCC seems to have no problem with this file, though:
$ gcc /usr/include/openssl/asn1.h -o asn1
$ ls asn1
asn1
The culprit seems to be the following macro use on line 556:
DECLARE_ASN1_ENCODE_FUNCTIONS_const(ASN1_SEQUENCE_ANY, ASN1_SEQUENCE_ANY)
Declared earlier on line 330:
type *d2i_##name(type **a, const unsigned char **in, long len); \
int i2d_##name(const type *a, unsigned char **out); \
DECLARE_ASN1_ITEM(name)
Any idea how I can go about dealing with this issue?
Hi,
I am finding that when I put an empty (ie, pointing to NULL) boost::shared_ptr into a std::vector, and then look at it in Python, the iteration and indexing results are different. That is,
X = myswigged.getListOfStuff()
for i,x in enumerate(X):
print ' iteration:', x
print ' indexing:', X[i]
produce different results; indexing notices that the empty (null) boost::shared_ptr is null and returns None; the iteration does not, producing a seemingly-valid boost::shared_ptr that will explode upon use.
Minimal test case: http://broiler.astrometry.net/~dstn/temp/test.tgz
wget http://broiler.astrometry.net/~dstn/temp/test.tgz
tar xzf test.tgz
python setup.py build_ext --inplace
python runtest.py
I have verified that this occurs in swig 2.0.10 and git master.
thanks,
dustin
It is not possible to apply %alias to native C functions. Code generation silently failes (with swigwin-2.0.6).
Example:
mod.i
%module mod
%{
#include "mod.h"
%}
%alias foo "bar";
%include "mod.h"
mod.h
#define bar foo
extern int foo(int i);
mod.c
#include "mod.h"
int foo(int i)
{
return i + 1;
}
We use an Intel compiler that has the following issues with the Python and Lua generated code. These changes should work fine in all compilers.
index 8803c66..2162f0f 100644
--- a/Lib/lua/luarun.swg
+++ b/Lib/lua/luarun.swg
@@ -720,7 +720,7 @@ SWIGINTERN int SWIG_Lua_iterate_bases(lua_State *L, swig_type_info * S
size_t bases_count;
int result = SWIG_ERROR;
int bases_table;
- (void)swig_type;
+ swig_type = NULL;
lua_getmetatable(L,first_arg);
/* initialise base search */
@@ -731,7 +731,7 @@ SWIGINTERN int SWIG_Lua_iterate_bases(lua_State *L, swig_type_info * S
bases_table = lua_gettop(L);
#else
/* In elua .bases table doesn't exist. Use table from swig_lua_class */
- (void)bases_table;
+ bases_table = NULL;
assert(swig_type!=0);
swig_module_info *module=SWIG_GetModule(L);
swig_lua_class **bases= ((swig_lua_class*)(swig_type->clientdata))->bases;
diff --git a/Lib/python/pyinit.swg b/Lib/python/pyinit.swg
index b44c2c8..fcb025b 100644
--- a/Lib/python/pyinit.swg
+++ b/Lib/python/pyinit.swg
@@ -377,11 +377,11 @@ SWIG_init(void) {
PyObject *thisown_descr;
int i;
- (void)builtin_pytype;
- (void)builtin_base_count;
- (void)builtin_basetype;
- (void)tuple;
- (void)static_getset;
+ builtin_pytype = NULL;
+ builtin_base_count = 0;
+ builtin_basetype = NULL;
+ tuple = NULL;
+ static_getset = NULL;
/* metatype is used to implement static member variables. */
metatype_args = Py_BuildValue("(s(O){})", "SwigPyObjectType", &PyType_Type);
diff --git a/Lib/python/pyrun.swg b/Lib/python/pyrun.swg
#ifdef SWIGPYTHON_BUILTIN
- (void)obj;
+ obj = NULL;
# ifdef PyWeakref_CheckProxy
if (PyWeakref_CheckProxy(pyobj)) {
pyobj = PyWeakref_GET_OBJECT(pyobj);
The following line, c++ direct initialization of a integer, leads to a parse error:
int a(3);
480: Error: Syntax error in input(1).
Furthermore, constants defined using direct initialization are not wrapped as constants:
const int b(static_cast<int>(ENUM_ITEM));
is translated as function with an argument.
In java.cxx and csharp.cxx at multiple lines you make the conversion of input argument by your own one.
It will better to use "in" typemap to do so.
When compiling to Java, I sometimes get the error given in title. I must confess that I have no idea of why reducing the constness should be an error anyhow.
This happens on kfreebsd-i386, kfreebsd-amd64 and sparc:
https://buildd.debian.org/status/fetch.php?pkg=simgrid&arch=kfreebsd-amd64&ver=3.11.1-1&stamp=1402116289
https://buildd.debian.org/status/fetch.php?pkg=simgrid&arch=kfreebsd-i386&ver=3.11.1-1&stamp=1402117802
https://buildd.debian.org/status/fetch.php?pkg=simgrid&arch=sparc&ver=3.11.1-1&stamp=1402118699
But this does not occurs on the other Debian architectures. I'm completely puzzeled, and any help would be welcomed. I'll use -fpermisive for the time being, but I don't quite like it.
The code that is compiled is visible here:
http://sources.debian.net/src/simgrid/3.11.1-1/src/bindings/java
Thanks for that wonderful piece of code by the way. It saved my soul :)
Directors for nested classes create an incorrect wrapped constructor call "wrap:action". The call should look like new namespace_class_nestedclass()
but instead is missing the containing class name and generates new namespace_nestedclass()
. I can resolve this by modifying https://github.com/swig/swig/blob/master/Source/Swig/cwrap.c#L1253 and retrieving "sym:name" from n
, the current node, instead of parent
. I don't understand near enough about the code to know if this is a correct fix or a horrible hack, so I'm not bothering with a PR in hopes that someone who is familiar with the code can comment.
Generated Lua bindings used to correctly inherit __tostring() from a parent class, but no longer do.
I'll attach a patch against an existing testcase which demonstrates the issue - before these changes, tostring() returns Foo
for both an object of class Foo and an object of class FooSub, but it no longer does.
Last two lines of output before these changes:
Foo
Foo
Output now:
Foo
<FooSub userdata: 0xddaa58>
git bisect shows the problem was introduced by this merge:
1be97ed Merge Lua changes - branch 'class_p1' of github.com:v-for-vandal/swig into v-for-vandal-class_p1
On that branch, this commit is the first where it fails, but many earlier ones aren't testable due to the segfault that was fixed here, so I doubt this is actually where the problem was introduced:
* ec629be (refs/bisect/bad) Fixing segfault
Passing -no-old-metatable-bindings to swig doesn't fix it - instead the testcase fails with:
/usr/bin/lua5.2: ./cpp_basic_runme.lua:45: attempt to index field 'global_fptr' (a nil value)
stack traceback:
./cpp_basic_runme.lua:45: in main chunk
[C]: in ?
Dear all,
I'm quite a newbee in compiling applications. While trying to install swig 1.3.40 during "make" execution I ran into
g++ -DHAVE_CONFIG_H -I../Source/Include -I../Source/CParse -I../Source/Include -I../Source/DOH -I../Source/CParse -I../Source/Preprocessor -I../Source/Swig -I../Source/Modules -g -O2 -Wall -W -ansi -pedantic -MT Modules/allegrocl.o -MD -MP -MF $depbase.Tpo -c -o Modules/allegrocl.o Modules/allegrocl.cxx &&\
mv -f $depbase.Tpo $depbase.Po
/tmp/ccG9S2WG.s: Assembler messages:
/tmp/ccG9S2WG.s:6369: Error: bad register name `%'
/tmp/ccG9S2WG.s:7280: Error: bad register name `%'
/tmp/ccG9S2WG.s:8259: Error: bad register name `%'
/tmp/ccG9S2WG.s:11930: Error: bad register name `%'
/tmp/ccG9S2WG.s:13747: Error: bad register name `%'
/tmp/ccG9S2WG.s:13751: Error: bad register name `%'
/tmp/ccG9S2WG.s:13884: Error: bad register name `%'
make[2]: *** [Modules/allegrocl.o] Error 1
make[2]: Leaving directory `/tmp/swig/swig-1.3.40/Source'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/swig/swig-1.3.40/Source'
make: *** [source] Error 2
Though I scanned all the usual source, I couldn't find a solution. I would be very glad if you can point me into the right direction.
Best
J.
i tried to generate swig for exisiing header files. The process fail with the mesage:
ericdef_gui.h(200): error : Syntax error in input(2).
The corresponding header code:
typedef int (STDCALL *T_GUI_EricMessageDialog) (
const char *text,
const char *caption,
int type
);
Help needed :-)
Thanks in advance
Oliver
The director_basic example seg faults on Travis OSX - https://travis-ci.org/swig/swig/builds/23270178. I can replicate it on Mountain Lion...
MountainLion:php william$ make director_basic.cpptest
if [ -f ./director_basic_runme.php ]; then echo "checking php testcase director_basic (with run test)" ; else echo "checking php testcase director_basic" ; fi;
checking php testcase director_basic (with run test)
make -f ../../../Examples/Makefile CXXSRCS="" SWIG_LIB="../../../Lib" SWIG=" ../../../preinst-swig" INCLUDES="-I../../../Examples/test-suite" SWIGOPT="-outcurrentdir -I../../../Examples/test-suite" NOLINK=true TARGET="director_basic" INTERFACEDIR="../../../Examples/test-suite/" INTERFACE="director_basic.i" php_cpp
../../../preinst-swig -php -cppext cxx -c++ -outcurrentdir -I../../../Examples/test-suite ../../../Examples/test-suite/director_basic.i
g++ -c -I/usr/local/include director_basic_wrap.cxx -I../../../Examples/test-suite -I/usr/local/Cellar/php54/5.4.27/include/php -I/usr/local/Cellar/php54/5.4.27/include/php/main -
I/usr/local/Cellar/php54/5.4.27/include/php/TSRM -I/usr/local/Cellar/php54/5.4.27/include/php/Zend -I/usr/local/Cellar/php54/5.4.27/include/php/ext -I/usr/local/Cellar/php54/5.4.27/include/php/ext/date/lib
g++ -bundle -undefined suppress -flat_namespace -I/usr/local/include director_basic_wrap.o -o director_basic.so
if [ -f ./director_basic_runme.php ]; then make -f ../../../Examples/Makefile PHP_SCRIPT=./director_basic_runme.php RUNTOOL="" php_run; elif [ -f ./director_basic.php -a ! -f ../../../Examples/test-suite/director_basic.list ]; then make -f ../../../Examples/Makefile PHP_SCRIPT=./director_basic.php RUNTOOL="" php_run; fi
php -n -q -d extension_dir=. -d safe_mode=Off ./director_basic_runme.php
make[1]: *** [php_run] Segmentation fault: 11
make: *** [director_basic.cpptest] Error 2
gdb stack trace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010
0x00000001003b33b8 in zend_fetch_property_address_read_helper_SPEC_UNUSED_CONST ()
(gdb) where
#0 0x00000001003b33b8 in zend_fetch_property_address_read_helper_SPEC_UNUSED_CONST ()
#1 0x000000010038ef23 in ZEND_FETCH_OBJ_FUNC_ARG_SPEC_UNUSED_CONST_HANDLER ()
#2 0x000000010035f5af in execute ()
#3 0x000000010033323c in zend_call_function ()
#4 0x0000000100350831 in zend_call_method ()
#5 0x000000010035add6 in zend_std_call_getter ()
#6 0x000000010035aab1 in zend_std_read_property ()
#7 0x00000001003b2f09 in zend_fetch_property_address_read_helper_SPEC_CV_CONST ()
#8 0x00000001003868d2 in ZEND_FETCH_OBJ_R_SPEC_CV_CONST_HANDLER ()
#9 0x000000010035f5af in execute ()
#10 0x000000010033323c in zend_call_function ()
#11 0x0000000100332a0a in call_user_function ()
#12 0x0000000101b459a4 in SwigDirector_MyClass::vmethod (this=0x101a75dc0, b={x = 3}) at director_basic_wrap.cxx:1658
#13 0x0000000101b4bb25 in MyClass::cmethod (this=0x101a75dc0, b=@0x101a795d0) at director_basic_wrap.cxx:1382
#14 0x0000000101b43d47 in _wrap_MyClass_cmethod (ht=2, return_value=0x101b94008, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at director_basic_wrap.cxx:2988
#15 0x00000001003a2a16 in zend_do_fcall_common_helper_SPEC ()
#16 0x000000010035f5af in execute ()
#17 0x000000010033e96c in zend_execute_scripts ()
#18 0x00000001002ed80b in php_execute_script ()
#19 0x00000001003c1e25 in do_cli ()
#20 0x00000001003c0ced in main ()
I don't think this a new problem as it also occurs with swig-2.0.12. php-5.3 is okay on this system though. Any suggestions for fixes or further debugging into I can supply from anyone familiar with the php api?
In the code below for C#/Java, the Minner and RightInside classes disappear and are not generated at all.
%feature("flatnested") Minner;
%inline %{
class Ooter {
class Minner {
class RightInside {
};
};
};
%}
@wkalinin would you mind taking a look?
There is an issue with swig and program using complete typename and typedef
for example
class B {
typedef int TYPE2;
};
Class A {
typedef B TYPE1;
};
class c {
typename A::TYPE1::TYPE2 a;
};
during the SwigType_typedef_resolve_all the typename "A::TYPE1::TYPE2"
will be splitted like this
prefix: A::B
basename: TYPE2
It will fail to find the scope associated to A::B and will resolve "A::TYPE1::TYPE2" as "A::TYPE1::TYPE2" and not int
Hey. I have just used swig to generate a wrapper for a c++ class. Unfortunately, I get this while compiling:
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:14: error: ‘zend_module_entry’ does not name a type
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:27: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:28: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:29: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:30: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:31: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:33: error: expected constructor, destructor, or type conversion before ‘(’ token
/Users/Ingwie/Work/php-ext/php-ewsc/php_easywsclient.h:34: error: expected constructor, destructor, or type conversion before ‘(’ token
make: *** [easywsclient.lo] Error 1
File in question is: https://gist.github.com/IngwiePhoenix/6898536
My config.m4 file is: https://gist.github.com/IngwiePhoenix/6898541
Any suggestions here? o.o
Currently D swig generated wrappers will only emit methods from the 1st parent of a class, eg: class A: public B1,B2,B3{}; will result in :
class A: B1{} and only show methods inherited from B1 plus new methods from A.
How about the following:
class A : B1{
private void*ptr;
this(void*ptr){...}
//either call it as or opCast, except opCast will hinder other casting cases
T as(T) if(is(T:B1)|| is(T:B2) || is(T:B3) ) {
return cast(T)ptr;
}
//optionally we can also add this:
alias as!B2 this;
//and once/if multiple alias this supported:
alias as!B3 this;
}
That way, methods inherited from B1,B2,B3 get supported at no cost:
auto a=new A;
a.B1_method1; //already available since A:B1
a.as!B2.B_method1; //already available since A:B1
a.as!B3.B_method1; //already available since A:B1
After updating swig to version 2.0.11, the functions
SWIGINTERN int SWIG_Lua_namespace_register(lua_State* L, swig_lua_namespace* ns)
and
SWIGINTERN int SWIG_Lua_add_namespace_details(lua_State* L, swig_lua_namespace* ns)
to return void when int was expected. This is fixed by the following patch:
diff --git a/Lib/lua/luarun.swg b/Lib/lua/luarun.swg
index 4d851bd..8485ed4 100644
--- a/Lib/lua/luarun.swg
+++ b/Lib/lua/luarun.swg
@@ -524,7 +524,7 @@ SWIGINTERN int SWIG_Lua_add_namespace_details(lua_State* L, swig_lua_namespace*
/* clear stack - remove metatble */
/* helper function. creates namespace table and add it to module table /
@@ -555,6 +555,7 @@ SWIGINTERN int SWIG_Lua_namespace_register(lua_State L, swig_lua_namespace* ns)
lua_setmetatable(L,-2); /* set metatable /
lua_rawset(L,-3); / add namespace to module table */
With swig @2.0.10 (devel)
and the latest clang from XCode 5 on Mac the swig-generated code in scipy
generates tons of warnings:
scipy/scipy#2944
Can you have a look if it's possible to adapt swig to generate code that results in fewer warnings?
After updating from SWIG 2.0.12 to 3.0.0 Lua wrappers that are generated for C++ code no longer compile under Visual Studio 2010.
Steps to reproduce:
Examples\lua\class
directoryswig.exe -c++ -lua example.i
cl.exe /c example_wrap.cxx /I path\to\lua\include\directory
Expected results:
Actual results:
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86
Copyright (C) Microsoft Corporation. All rights reserved.
example_wrap.cxx
example_wrap.cxx(1722) : error C3861: 'snprintf': identifier not found
The above description assumes that swigwin-3.0.0 (executable and source code) is used.
As far as I can tell, other versions of Visual Studio are affected by this issue as well: the snprintf
function is still missing in VS 2013.
This causes problems with eg
(cl:defmacro defanonenum (&body enums)
"Converts anonymous enums to defconstants."
`(cl:progn ,@(cl:loop for value in enums
for index = 0 then (cl:1+ index)
when (cl:listp value) do (cl:setf index (cl:second value)
value (cl:first value))
collect `(cl:defconstant ,value ,index))))
when the current package does not use :common-lisp
. Some other =lambda-list-keywords= are already qualified with cl:
, but all of them should be.
PS.: Sorry for not using the sf.net bug tracker, I gave up after three 500 errors.
Due to some Qt-specific things like "Signal/Slot, QObject parenting ownership, Qt Properties, QVariant, and custom classes for string, vectors, etc.", it's current not possible to generate full Qt bindings using SWIG.
Creating a github issue for the ideas recently discussed in here and here in the hopes of broader awareness and call for help.
D swig generated wrappers shows 'public' for methods.
That's redundant for D, where public is by default.
Hi,
I got a warning with swig 2.0.9 when compiling a python wrapper with clang 3.2:
In the embedded function SWIG_Python_ConvertPtrAndOwn:
res = SWIG_AddCast(res);
The compiler output:
/home/michel/projects/libftdi/build_py3/bindings/ftdi1PYTHON_wrap.c:2369:23: warning: explicitly assigning a variable of type 'int' to itself [-Wself-assign]
res = SWIG_AddCast(res);
~~~ ^ ~~~
2 warnings generated.
Regards,
M.
r fails this regression test. The problem is that R should add the namespace to the internal methods.
This is a strange bug which is probably best shown with an example:
$ cat -n ut.i
1 %module ut
2
3 %ignore *::Foo;
4 %rename("%s") T::Foo;
5 //%rename("%s") T<int>::Foo;
6
7 %inline %{
8 template <typename V> struct T {
9 V Foo();
10 V Bar();
11 };
12
13 struct S {
14 void Foo();
15 void Bar();
16 };
17 %}
18 %template(IntT) T<int>;
$ swig -csharp -c++ -o wrap_ut_csharp.cpp ut.i
$ fgrep Foo *.cs || echo "Foo not exported"
Foo not exported
Uncommenting line 5 makes it work as expected, i.e. T::Foo()
is exported. But both line 5 and line 4 are needed, if either one is omitted, Foo()
is ignored.
Also notice that this is related to %ignore
, without it, i.e. if we use %rename(Baz)
on Foo()
, line 4 on its own works just fine.
This was first reported in this thread
There are 3 different strong enums defined, like this:
enum class /* name */
{
// ...
Invalid,
// ...
}
When using latest HEAD version of swig, I get following:
/[...]/MapRendererTypes.h:14: Error: 'Invalid_get' is multiply defined in the generated target language module in scope 'OsmAndCoreJNI'.
/[...]/MapTypes.h:30: Error: Previous declaration of 'Invalid_get'
/[...]/MapStyle.h:24: Error: 'Invalid_get' is multiply defined in the generated target language module in scope 'OsmAndCoreJNI'.
/[...]/MapTypes.h:30: Error: Previous declaration of 'Invalid_get'
I believe that this is wrong, since "Invalid" doesn't belong to global scope (since it's enum class, not enum). Taking into account that current HEAD is unstable 3.0.0, I wonder if enum classes are already supported, or they are just treated as regular enums.
I wrote a .i file and generated C# wrapper on swig 3.0.0
typedef unsigned int utf32;
%typemap(ctype) const utf32* "utf32*"
%typemap(ctype) utf32* "utf32*"
class TestClass
{
public:
void Test( const utf32* v);
static void TestStatic( const utf32* v);
};
The wrapper is generated as follows.
SWIGEXPORT void SWIGSTDCALL CSharp_TestClass_Test(void * jarg1, utf32* jarg2) {
TestClass *arg1 = (TestClass *) 0 ;
utf32 *arg2 = (utf32 *) 0 ;
arg1 = (TestClass *)jarg1;
arg2 = (utf32 *)jarg2;
(arg1)->Test((utf32 const *)arg2);
}
SWIGEXPORT void SWIGSTDCALL CSharp_TestClass_TestStatic(utf32* jarg1) {
utf32 *arg1 = (utf32 *) 0 ;
arg1 = (utf32 *)jarg1;
TestClass::TestStatic((unsigned int const *)arg1);
}
In the member function, arg2 is cast to utf32 const_.
On the other hand, in the static member function, arg1 is cast to unsigned int cont_.
Normally, it is no problem. But I think that it is a bug.
Reference: http://sourceforge.net/mailarchive/message.php?msg_id=30914596
%swig_fromcplx_conv calls rb_complex_new() which is available from Ruby 1.9 on only
In Swig 2.0.4, wrapping a std::multimap fails with an error.
Copying the SWIG_Traits_frag(std::pair<>) from std/std_map.i into std/std_multimap.i eliminated the error messages.
When trying to use c++11 mode with clang, i.e. the -std=c++11 -stdlib=libc++ flags are set, the swig generated cxx cannot be compiled.
An example of the error:
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:11297:24: error: no matching member function for call to 'erase'
result = (arg1)->erase(arg2);
~~~~~~~~^~~~~
/usr/bin/../lib/c++/v1/vector:716:76: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
__attribute__ ((__visibility__("hidden"), __always_inline__)) iterator erase(const_iterator __position);
^
/usr/bin/../lib/c++/v1/vector:717:14: note: candidate function not viable: requires 2 arguments, but 1 was provided
iterator erase(const_iterator __first, const_iterator __last);
^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:11376:24: error: no matching member function for call to 'erase'
result = (arg1)->erase(arg2,arg3);
~~~~~~~~^~~~~
/usr/bin/../lib/c++/v1/vector:717:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator erase(const_iterator __first, const_iterator __last);
^
/usr/bin/../lib/c++/v1/vector:716:76: note: candidate function not viable: requires single argument '__position', but 2 arguments were provided
__attribute__ ((__visibility__("hidden"), __always_inline__)) iterator erase(const_iterator __position);
^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:11982:24: error: no matching member function for call to 'insert'
result = (arg1)->insert(arg2,(std::vector< int >::value_type const &)*arg3);
~~~~~~~~^~~~~~
/usr/bin/../lib/c++/v1/vector:686:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator insert(const_iterator __position, const_reference __x);
^
/usr/bin/../lib/c++/v1/vector:688:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator insert(const_iterator __position, value_type&& __x);
^
/usr/bin/../lib/c++/v1/vector:712:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator insert(const_iterator __position, initializer_list<value_type> __il)
^
/usr/bin/../lib/c++/v1/vector:702:9: note: candidate function template not viable: requires 3 arguments, but 2 were provided
insert(const_iterator __position, _InputIterator __first, _InputIterator __last);
^
/usr/bin/../lib/c++/v1/vector:709:9: note: candidate function template not viable: requires 3 arguments, but 2 were provided
insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);
^
/usr/bin/../lib/c++/v1/vector:694:14: note: candidate function not viable: requires 3 arguments, but 2 were provided
iterator insert(const_iterator __position, size_type __n, const_reference __x);
^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:12063:15: error: no matching member function for call to 'insert'
(arg1)->insert(arg2,arg3,(std::vector< int >::value_type const &)*arg4);
~~~~~~~~^~~~~~
/usr/bin/../lib/c++/v1/vector:694:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<int>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator insert(const_iterator __position, size_type __n, const_reference __x);
^
/usr/bin/../lib/c++/v1/vector:702:9: note: candidate template ignored: deduced conflicting types for parameter '_InputIterator' ('unsigned long' vs. 'int')
insert(const_iterator __position, _InputIterator __first, _InputIterator __last);
^
/usr/bin/../lib/c++/v1/vector:709:9: note: candidate template ignored: deduced conflicting types for parameter '_ForwardIterator' ('unsigned long' vs. 'int')
insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);
^
/usr/bin/../lib/c++/v1/vector:686:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
iterator insert(const_iterator __position, const_reference __x);
^
/usr/bin/../lib/c++/v1/vector:688:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
iterator insert(const_iterator __position, value_type&& __x);
^
/usr/bin/../lib/c++/v1/vector:712:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
iterator insert(const_iterator __position, initializer_list<value_type> __il)
^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:14674:24: error: no matching member function for call to 'erase'
result = (arg1)->erase(arg2);
~~~~~~~~^~~~~
/usr/bin/../lib/c++/v1/vector:716:76: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
__attribute__ ((__visibility__("hidden"), __always_inline__)) iterator erase(const_iterator __position);
^
/usr/bin/../lib/c++/v1/vector:717:14: note: candidate function not viable: requires 2 arguments, but 1 was provided
iterator erase(const_iterator __first, const_iterator __last);
^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:14753:24: error: no matching member function for call to 'erase'
result = (arg1)->erase(arg2,arg3);
~~~~~~~~^~~~~
/usr/bin/../lib/c++/v1/vector:717:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator erase(const_iterator __first, const_iterator __last);
^
/usr/bin/../lib/c++/v1/vector:716:76: note: candidate function not viable: requires single argument '__position', but 2 arguments were provided
__attribute__ ((__visibility__("hidden"), __always_inline__)) iterator erase(const_iterator __position);
^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:15359:24: error: no matching member function for call to 'insert'
result = (arg1)->insert(arg2,(std::vector< double >::value_type const &)*arg3);
~~~~~~~~^~~~~~
/usr/bin/../lib/c++/v1/vector:686:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator insert(const_iterator __position, const_reference __x);
^
/usr/bin/../lib/c++/v1/vector:688:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator insert(const_iterator __position, value_type&& __x);
^
/usr/bin/../lib/c++/v1/vector:712:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator insert(const_iterator __position, initializer_list<value_type> __il)
^
/usr/bin/../lib/c++/v1/vector:702:9: note: candidate function template not viable: requires 3 arguments, but 2 were provided
insert(const_iterator __position, _InputIterator __first, _InputIterator __last);
^
/usr/bin/../lib/c++/v1/vector:709:9: note: candidate function template not viable: requires 3 arguments, but 2 were provided
insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);
^
/usr/bin/../lib/c++/v1/vector:694:14: note: candidate function not viable: requires 3 arguments, but 2 were provided
iterator insert(const_iterator __position, size_type __n, const_reference __x);
^
/Users/wiking/shogun/build/src/interfaces/ruby_modular/modshogunRUBY_wrap.cxx:15440:15: error: no matching member function for call to 'insert'
(arg1)->insert(arg2,arg3,(std::vector< double >::value_type const &)*arg4);
~~~~~~~~^~~~~~
/usr/bin/../lib/c++/v1/vector:694:14: note: candidate function not viable: no known conversion from 'SwigValueWrapper<std::vector<double>::iterator>' to 'const_iterator' (aka '__wrap_iter<const_pointer>') for 1st argument
iterator insert(const_iterator __position, size_type __n, const_reference __x);
^
/usr/bin/../lib/c++/v1/vector:702:9: note: candidate template ignored: deduced conflicting types for parameter '_InputIterator' ('unsigned long' vs. 'double')
insert(const_iterator __position, _InputIterator __first, _InputIterator __last);
^
/usr/bin/../lib/c++/v1/vector:709:9: note: candidate template ignored: deduced conflicting types for parameter '_ForwardIterator' ('unsigned long' vs. 'double')
insert(const_iterator __position, _ForwardIterator __first, _ForwardIterator __last);
^
/usr/bin/../lib/c++/v1/vector:686:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
iterator insert(const_iterator __position, const_reference __x);
^
/usr/bin/../lib/c++/v1/vector:688:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
iterator insert(const_iterator __position, value_type&& __x);
^
/usr/bin/../lib/c++/v1/vector:712:14: note: candidate function not viable: requires 2 arguments, but 3 were provided
iterator insert(const_iterator __position, initializer_list<value_type> __il)
^
8 errors generated.
I am getting the error below when trying to wrap boost::units.
'''/usr/include/boost/units/quantity.hpp:50: Error: Syntax error in input(1).
error: command 'swig' failed with exit status 1'''
i think it is related to the > symbol in the line below. Is there any workaround to wrap this while it is being fixed in swig?
struct is_narrowing_conversion_impl : mpl::bool_< (sizeof(Source) > sizeof(Destination)) > {};
The type-checking code SWIG generates in overload-resolution wrapper functions incorrectly ignores INPUT typemaps (although these typemaps are correctly used inside the per-overload wrapper function that does the actual argument conversion and calling).
This means that when one tries to call the overloaded function from the target language with some value which the INPUT typemap should convert, the overload-resolution wrapper thinks it's the wrong type, and in most cases that means overload resolution will fail and it will signal a type error.
I noticed this problem with the Lua backend, although I don't know if it's specific to that backend or a more general issue.
Here's a test case that illustrates the problem (instructions for compiling etc are in the comments):
https://gist.github.com/snogglethorpe/7521146
[I'm not actually sure how SWIG would do this correctly though, as typemaps don't seem to have a way of specifying code to just check the type...]
Dear SWIG community:
I use GCC 4.8 with SWIG 3.0.0 and Lua.
The compiler g++ is run with -Wall -Werror .
When compiling the generated wrapper code, the compiler complains on several issues:
unused variable 'begin' [-Wunused-variable]
-> This appears multiple times in the line
int begin = lua_gettop(L);
I found a workaround adding
if (begin==0){;}
to the same line to luaswig.swg using 'sed'. One can not replace the line by
lua_gettop(L);
since in some C++ functions, the variable begin is indeed used.
Unused parameter 'swig_type' in luaswig.swg, line:
SWIGINTERN int SWIG_Lua_iterate_bases(lua_State L, swig_type_info * swig_type, int first_arg, swig_lua_base_iterator_func func, int const ret)
Here I tried to resolve the problem by commenting out swig_type, but at another point in my project I enhance the SWIG-Lua bindings using
#include "luarun.swg"
in a C++ source file. If I remove swig_type from the parameter list, the compiler complains that it needs the parameter at that point.
warning: unused parameter 'first_arg' [-Wunused-parameter]
in
SWIGINTERN int SWIG_Lua_class_do_get(lua_State *L, swig_type_info *type, int first_arg, int *ret)
In the wrapper code, I have multiple compiler warnings
XYZ defined, but not used (-Werror=unused-variable)
XYZ are entries like swig_string_constants and swig_string_Sf_SwigStatic_meta (with a class string being wrapped), swig_SwigModule_meta
There is even a compile error of a wrong cast. Here you need to replace
(unsigned long)lua_touserdata(L,1)
by
reinterpret_cast<size_t>(lua_touserdata(L,1))
To ensure quality control, I can not switch off -Wall -Werror in my project. Until SWIG 2.0.11 I was able to use a sequence of sed commands to find work arounds. But in this case, I would be very grateful if some of the SWIG developers could fix this issue.
Best regards
Sebastian
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.