[Pythonmac-SIG] Re: C Extension Modules and GUSI

Jack Jansen jack@oratrix.com
Tue, 5 Feb 2002 11:40:12 +0100


On Tuesday, February 5, 2002, at 03:57 , Martin Miller wrote:

> So far there haven't been any response to my GUSI questions and I can't
> help wonder if it's because:
>  0) Nobody reads the list on the weekend, or
>  1) Nobody understand the question,
>  2) It's a too dumb newbie question,
>  4) Nobody knows,
>  3) No one cares. ;-(

It's actually
   5) Jack was going to answer but forgot.

>> My question is: Is it necessary to use the GUSI headers when building C
>> Extension modules that will become dynamically-linked shared libraries.
>> One reason I ask is because the GUSI 2 documentation talks about 
>> putting
>> the GUSI include folder in front of all other system include access
>> paths, and likewise, generally putting the GUSI libraries ahead of most
>> others for the link step.

The answer is: it depends. If your extension module does not use stdio, 
sockets or any of the unix-compatibility routines 
(open/close/read/write, signal, readdir, stat, etc) you can safely build 
without using GUSI. But if your module does use any of these (or if 
you're not sure) you'd better use the GUSI includes, otherwise you may 
be compiling with the MSL definition of, say, struct stat, while the 
stat() routine you'll be linked against will have been compiled with the 
GUSI variant of struct stat.

Even in the latter situation you may be able to get away with not using 
the GUSI includes, but only if you know what you're doing (i.e. not 
running into the struct conflict situation above). But note that it's 
not only struct definitions, there are also a couple of #defines that 
are different and a few other things.

Note that you shouldn't link against the GUSI libraries: GUSI is 
included in PythonCore (and all symbols are exported from there).
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -