Wrapping Python ?

Roger Binns rogerb at rogerbinns.com
Sun Sep 26 04:11:55 CEST 2004

Cameron Laird wrote:
> Exactly:  taking care of shared libraries as you describe (I *think*
> Starkits currently assume responsibility for writing 'em into the
> real file system, and loading from there) (and, yes, I know that
> has security consequences) is one of Starkit's benefits.

In that case McMillan installer will do the same thing.  There is
absolutely no way I would distribute software that extracted
libraries to bits of the filesystem every time it runs on any
platform.  However others have no such qualms :-)

I did some more digging on StarKit and it looks like they build
the main executable statically linked with the most common libraries
(eg Tk).  Then they require that every extension library is built
using Stubs (http://mini.net/tcl/stubs) and use a builtin mechanism
for dynamically loading the extension.  That still doesn't solve
the issue for OS level linking (eg when using wxPython on Linux,
there is linkage between the wxPython library into the wxWidgets
library into GTK into X).  Typically the wxPython and wxWidgets
libraries are included with the application, and it wouldn't
be feasible to use something like Stubs with the wxWidgets
library, especially since it isn't directly tied to a scripting
language and exports a huge number of functions and C++ classes.

Other than extracting libraries at runtime into the real filesystem
I can only see this to be doable by re-implementing the
operating system dynamic loader.


More information about the Python-list mailing list