Python wrapper for the Fast Light Toolkit pyFLTK








Boost::Python vs SWIG (Aug 28, 2003)

There was some discussion whether pyFLTK should be developed using Boost::Python rather than SWIG. The consensus so far is the following:
The result of all this is that there was no reason to change the strategy midway, or as they say: never change a winning horse (or similar).


Undefined symbol _Znwj (updated Nov 12, 2003)

According to Hugues Talbot:
This is caused by the C++ library not being available at all to the final library.
In the RedHat 9 case I got the above problem. It was fixed by substituting `c++' for `gcc' in the linking stage, i.e the last line of the result of `python ./ build' should be something like:
You can verify whether this is a problem in your case by checking the compiler versions used for building Python and for the extension. You can find out the version of the compiler that was used for building Python by starting the Python interpreter. The version of the compiler installed on your system you might get like this:
c++ -v
If they are equal then very likely the above procedure should help you. To force the usage of c++ (or g++) for linking, proceed as follows:
export LDSHARED=c++
python build

This problem should only occur for versions of Python before 2.3. For Python 2.3, the new version of distutils will select c++ for building whenever the source file has an extension of the form cxx or cpp, which is the case for the pyFLTK extension.


Compilation using MinGW (Aug 28, 2003)

Compilation with the MinGW environment has been tested for MinGW version 2.0.0 using the MSYS environment version 1.0.9. See here for a more detailed description of the build process.

Compilation using Cygwin (Aug 28, 2003)

Compilation with the Cygwin environment has been tested and is equivalent to the compilation using the MinGW environment.

Mac OS X:

Compilation seems possible for Mac OS X. See the installation page for details on what to do.