pyobjc / Doc / gnustep.html

The branch 'pyobjc-ancient' does not exist.
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">
<html xmlns="" xml:lang="en" lang="en">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
GNUstep support in PyObjC</title>
<h2>GNUstep support in PyObjC</h2>
<p>PyObjC has limited support for GNUstep, the 'objc' and 'Foundation' packages
build and pass some, but by far not all, unittests. More work is needed to
make the GNUstep port as stable as the MacOS X &quot;port&quot;.</p>
<p>The GNUstep port was primarily developed on Linux i86 (specifically 
the Debian testing distribution), using python 2.3.3,  gcc 3.3.2 and 
gnustep-base1 1.9.0-1. The code in works for this configuration,
but probably not for other configurations.</p>
<p>GNUstep support is <i>very</i> fragile, in some versions of the the selectors for
new classes should be strings, in others they should be SEL objects (as you
would expect). We also use undocumented private functions to initialize new
<h2><a name="todo">TODO</a></h2>
<li>[Serious] Fix linkage problems. The objC runtime doesn't seem to be 
initialized correctly and/or the classes in newly loaded frameworks are
not correctly registered in the runtime.</li>
<li>Fix the odd bug...<p>I currently get the following text when importing objc:</p>
Unable to retrieve information about SIGPIPE
<p>This text is not printed by PyObjC and I haven't been able to find who
does print that text...</p>
<li>Fix bugs found using the unittests<p>runPyObjCTests finds some problems that disappear when those tests 
are run separately...</p>
<li>Extract more CFLAGS and LDFLAGS information from the GNUstep build system,
instead of hard-coding the information</li>