Getting these kind of errors on Appveyor which uses mingw/cygwin to run
a Python interpreter:
Native windows Python 3.6 running under cygwin and mingw Python 3.7 running under mingw:
Fatal Python error: _Py_HashRandomization_Init: failed to get random
numbers to initialize Python
Cygwin Python 2.7 running under cygwin:
0 [main] python2.7 496 child_info_fork::abort: address space needed by '_foo.dll' (0x6D0000)
is already occupied
* adr26-master:
Cleanup accessing/decref of globals, to avoid code bloat in init function.
Fix ISOC build errors.
Fix unused variable warning.
#1360: Leak of SWIG var link object
Conflicts:
CHANGES.current
When using -builtin, the two step C-extension module import is now
one step and the wrapped API is only available once and not in an underlying
module attribute like it is without -builtin. To understand this, consider a
module named 'example' (using: %module example). The C-extension is compiled into
a Python module called '_example' and a pure Python module provides the actual
API from the module called 'example'. It was previously possible to additionally
access the API from the module attribute 'example._example'. The latter was an
implementation detail and is no longer available. It shouldn't have been used, but
if necessary it can be resurrected using the moduleimport attribute described in the
Python chapter of the documentation. If both modules are provided in a Python
package, try:
%module(moduleimport="from . import _example\nfrom ._example import *") example
or more generically:
%module(moduleimport="from . import $module\nfrom .$module import *") example
and if both are provided as global modules, try:
%module(moduleimport="import _example\nfrom _example import *") example
or more generically:
%module(moduleimport="import $module\nfrom $module import *") example
The module import code shown will appear in the example.py file.
The implementation for a renamed constructor for -builtin no longer
uses the same implementation for non-builtin mode which makes a call
into the compiled C module, eg _constructor_rename for a module called
constructor_rename. The output in the constructor_rename.py file is now:
RenamedConstructor = new_RenamedConstructor
instead of
def RenamedConstructor():
val = _constructor_rename.new_RenamedConstructor()
return val
when wrapping:
struct Foo {
%rename(RenamedConstructor) Foo();
Foo() {}
};
See the constructor_rename.i testcase.
This change has been made to make the wrapper more efficient and is a
step towards the next commit which will remove duplicating the symbols
in both the pure Python module and implementation C module
(constructor_rename and _constructor_rename respectively in this case).
Code handling %template in the parser created a totally new top-level
module child of namespace type when handling templates inside a
namespace and copied the nodes from the previously parsed C++ template
declaration to it. However copies of this node kept their original
values of "abstracts" attribute, which contained pointers to the classes
in the original template declaration, i.e. outside of the subtree
created for the instantiated template. This, in turn, meant that during
the types resolution pass, the code in TypePass did not update the types
used in the methods of the classes appearing in the "abstracts" List,
even though it did update the types for the children of the instantiated
template subtree.
And this finally resulted in wrongly detecting overridden virtual
methods as abstract in Allocate::is_abstract_inherit() during the next
pass, as the signatures of the overridden method -- using resolved types
-- and of the method from the class pointed to by "abstract" -- using
the original types from C++ code -- didn't match.
Resolve this simply by not copying "abstracts" attributes when creating
the template subtree and doing another pass over this tree to recreate
them using the new nodes, just as it's already done for "defaultargs"
attribute, presumably for similar reasons. Note that doing another pass
over the tree is not as efficient as doing everything in a single pass,
but merging the new update_abstracts() with update_defaultargs() is not
completely obvious, so for now keep it simple and optimize it later if
necessary.
Also, add a test checking for the situation described above.
Closes#1353.
When using the moduleimport option, such as:
%module(moduleimport="import $module") example
the minimum Python version check disappeared from the generated Python
file. The code has been refactored and _swig_python_version_info is
no longer deleted after initial use as it can be used in a few places,
in particular, when -builtin is used.
Set paths correctly for msys2 + mingw. With this correction, there is no
need to override the default gcc.
Provide a way to specify the name of the python interpreter using
a WITHLANG env variable. Needed where the native python3 executable is
called python.exe which is needed and not MinGW's pre-installed python3.exe.
This option turned off the insertion of Python import statements
derived from a %import directive. For example given:
%module module_b
%import "module_a.i"
then module_b.py will contain:
import module_a
This option was originally added in 658add5, apparently to fix some sort
of circular import problem of which there are no details. It is
undocumented and is now removed as part of the simplification of the
SWIG Python command line options for SWIG 4.
Issue #1340.
Both the command line and %module options of the same name have been
removed. These were undocumented. The -outputtuple option returned a
Python tuple instead of a list, mostly typically in the OUTPUT
typemap implementations.
It unclear why a tuple instead of a list return type is needed and
hence this option has been removed as part of the simplification of
the SWIG Python command line options for SWIG 4.
Issue #1340.
The -cppcast option is still turned on by default. The -nocppcast option
to turn off the use of c++ casts (const_cast, static_cast etc) has been
removed. However, defining SWIG_NO_CPLUSPLUS_CAST will still generate C casts
instead of C++ casts for C++ wrappers.
This a revert of commit fc79264a48:
"Revert "Remove -cppcast and -nocppcast command line options""
The Scilab and Javascript casting problems are now fixed, so -cppcast
is now switched on as default.
The function pointer typemaps were not being used when the function
pointer is const, like ADD_BY_VALUE_C in the funcptr_cpp.i testcase:
%constant int (* const ADD_BY_VALUE_C)(const int &, int) = addByValue;
Problem affecting Javascript and observable when running test-suite with -cppcast.
The -cppcast option is still turned on by default. The -nocppcast option
to turn off the use of c++ casts (const_cast, static_cast etc) has been
removed. However, defining SWIG_NO_CPLUSPLUS_CAST will still generate C casts
instead of C++ casts for C++ wrappers.
This option controlled the __repr__ proxy class method.
Also removes:
-old_repr
-oldrepr
-new_repr
-newrepr
Note: -newrepr was and remains on by default. When -oldrepr/-old_repr
option resulted in code that did not run.
This option was for backwards compatibility with very old versions of
SWIG that generated a shadow 'XPtr' class derived from proxy class X.
If anyone is still using these, they are best off using the actual proxy
class, or otherwise add them in manually using %pythoncode.
Issue #1340.
