3d6880aad1
The proxy layer, and all the extra complexity associated with it, seemed to be only necessary in order to try to allow using the same name for the wrapped global functions as were used for them in the original C or C++ code being wrapped. However this could simply never work in all cases, notably it didn't work at all when using ELF shared libraries under Unix as the functions with the same name defined in the main program were interposed and replaced the functions defined in the shared library, meaning that the proxy function foo() called wrapper function _wrap_foo() which called back into proxy function foo() itself again, resulting in guaranteed stack overflow. The only possible way to fix this would be to use "protected" ELF visibility for the original functions, but this is not always possible (e.g. if the sources of the original library are not available) and not simple even when it is and, besides, protected visibility has its own problems -- notably by making it impossible to hook the library functions when you actually want to do it. Besides, proxy-based approach simply couldn't work at all when using static linking as it resulted in two copies of the function with the same name Most importantly, however, the main task of this module is to wrap C++ classes, not C functions, and renaming them in the wrapper is not necessary at all in this case as there is no conflict with the original names in this case. So simply drop the idea of generating a separate proxy header and generate a header declaring the functions declared in the wrapper instead and, also, do not give them "_wrap_" prefix whenever possible, i.e. only do it for the global functions. This simplifies SWIG code itself and makes it simpler to use its output as it's not necessary to link both with the wrapper (dynamically) and with the proxy (statically) and it's not enough to link with the wrapper only and it can be done in any way (i.e. either statically or dynamically). As a side effect of this change, Swig_name_proxy() is not necessary any more and was removed, eliminating the only difference with the master branch in any source file other than c.cxx itself. |
||
|---|---|---|
| .. | ||
| android | ||
| c | ||
| chicken | ||
| contract | ||
| csharp | ||
| d | ||
| go | ||
| guile | ||
| java | ||
| javascript | ||
| lua | ||
| modula3 | ||
| mzscheme | ||
| ocaml | ||
| octave | ||
| perl5 | ||
| php | ||
| pike | ||
| python | ||
| r | ||
| ruby | ||
| s-exp | ||
| scilab | ||
| tcl | ||
| test-suite | ||
| xml | ||
| index.html | ||
| Makefile.in | ||
| README | ||
SWIG Examples
The subdirectories of "Examples" named after SWIG's language backends
contain a number of simple examples that are primarily used for testing.
The file 'index.html' is the top of a hyperlinked document that
contains information about all of the examples along with various
notes related to each example.
Note: All of the examples rely upon the Makefile in this directory.
You may need to edit it to reflect the configuration of your machine
in case the configure script guesses incorrect settings.
*** Special note concerning C++ ***
The configure script is currently unable to handle all of the possible
options for producing dynamically loadable C++ extensions. Here are
the rules of thumb for making C++ work:
- Try using the C++ as the linker for the shared library. For example:
g++ -shared $(OBJS) -o module.so
- If that doesn't work, you may need to explicitly link against some
kind of C++ runtime library. For example:
ld -G $(OBJS) -L/opt/SUNWspro/lib -lCrun -o module.so
This can be set by modifying the setting of CPP_DLLIBS in the
Makefile.
*** Special note for SWIG Maintainers ***
When you add an example, consider arranging for the example to be also
useful as part of the SWIG testing framework. To do this, include in
the example makefile a target "check" ("check: all" is sufficient for a
first pass), and add an invocation to ../Makefile.in under target
"check-examples" (or whatever is appropriate). Later, we can add or
expand the actions under target "check" to do more in-depth testing.