3.6. Q. Link errors building Python with STDWIN on SGI IRIX.
A. Rebuild STDWIN, specifying "CC=cc -cckr" in the Makefile.
3.7. Q. Link errors for dlopen, dlsym, dlerror from import.o.
A. You are probably using the GNU loader which doesn't understand
dynamic linking. Manually comment out #define HAVE_DLFCN_H from
config.h. (Should be fixed in 1.0.1.)
3.8. Q. Link errors after rerunning the configure script.
A. It is generally necessary to run "make clean" after a configuration
change.
3.9. Q. The python interpreter complains about options passed to a
script (after the script name).
A. You are probably linking with GNU getopt, e.g. through -liberty.
Don't. (If you are using this because you link with -lreadline, use
the readline distributed with Python instead.)
3.10. Q. When building on the SGI, make tries to run python to create
glmodule.c, but python hasn't been built or installed yet.
A. Comment out the line mentioning glmodule.c in Setup and build a
python without gl first; install it or make sure it is in your $PATH,
then edit the Setup file again to turn on the gl module, and make
again. You don't need to do "make clean"; you do need to run "make
Makefile" in the Modules subdirectory (or just run "make" at the
toplevel).
3.11. Q. Intermittent core dumps and complaints about perfectly valid
argument lists to built-in functions (e.g. posix.stat(filename) says
"no arguments needed").
A. You are probably using <stdarg.h> instead of <varargs.h>, or the
other way around. It may also be that your <stdarg.h> or <varargs.h>
does not match the code generated by your compiler. In simple cases,
it may help to turn comment out the #define HAVE_STDARG_H from the
generated config.h.
3.12. Q. Trouble building Python 1.0.0 on NeXT.
A. Manually add #define _POSIX_SOURCE to config.h. (Should be fixed
in 1.0.1.)
3.13. Q. Other trouble building Python 1.0.0 on platform X.
A. Please email the details to <guido@cwi.nl> and I'll look into it.
4.1. Q. Is there a source code level debugger with breakpoints, step,
etc.?
A. Yes. Check out module pdb; pdb.help() prints the documentation (or
you can read it as Lib/pdb.doc). If you use the STDWIN option,
there's also a windowing interface, wdb. You can write your own
debugger by using the code for pdb or wdb as an example.
4.9. Q. I have a module in which I want to execute some extra code when it
is run as a script. How do I find out whether I am running as a
script?
A. A module can find out its own module name by alooking at the
(predefined) global variable __name__. If this has the value
'__main__' you are running as a script. E.g. if you put the following
on the last line of your module, main() is called only when your
module is running as a script:
if __name__ == '__main__': main()
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>