[Pythonmac-SIG] weirdness with Mac OS 9 extension
Jack.Jansen at cwi.nl
Mon Aug 25 11:49:05 EDT 2003
the only thing I can think of is that somehow the GUSI stdio library
MSL stdio library are getting mixed up. First thing to do is to check
that the libraries are in the right order. If you look at the link
you should first have your gusiconfig, then gusi_msl, then gusi_core
then all your other files. Also, carefully check the warning messages
build step, there should be warnings about fopen() and fread() from
being used in stead of those from MSL.
If that seems okay there may still a way that fread() from MSL got
with fopen() from GUSI, although I've never seen it myself. You could
a link map, and checking the filenames from which the relevant routines
are pulled in.
If this also fails to provide a solution it may be that you are indeed
everything from GUSI but something is wrong at a lower level. Build the
variants of the GUSI libraries, link against those and step in to fread
to see what the problem is.
On Saturday, August 23, 2003, at 10:53 AM, Robin Becker wrote:
> Hi I'm throwing this out in the hope that someone else has seen the
> ssame kind of
> With Just van Rossum and Jack Jansen's help we've created a compact
> distro for a client, but so far all our attempts at getting the
> extensions built in
> house (rather than by Just) have failed. We have Code Warrior patched
> to 8.3 and
> have been using the mcp files contributed by Just (with file paths
> changed to match
> our system).
> Even so in at least one module _renderPM we get a strange error at run
> time in the
> following code
> f = fopen (filename, "rb"); /*f is non NULL supposedly a good
> if (f == NULL) return NULL;
> pfb_size = 0;
> pfb_size_max = 32768;
> pfb = gt1_new (char, pfb_size_max);
> while (1)
> bytes_read = fread (pfb + pfb_size, 1, pfb_size_max -
> pfb_size, f);
> /*the first fread returns zero*/
> if (bytes_read == 0) break;
> pfb_size += bytes_read;
> gt1_double (pfb, char, pfb_size_max);
> /*errno here is 9 (ie bad file descriptor)*/
> fclose (f);
> ie we get a non null descriptor, but the first fread seems to treat it
> as bad.
> We have GUSI2 & Python/include on the paths list and supposedly the
> right things on
> the linker path, but this code just doesn't work.
> If I try the above in a console linked in the standard way things work
> as expected
> as does the binary created by Just.
> Anyone with any good ideas?
> Robin Becker
> Pythonmac-SIG maillist - Pythonmac-SIG at python.org
Jack Jansen, <Jack.Jansen at cwi.nl>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma
More information about the Pythonmac-SIG