Python Language FAQ - Section 3

This FAQ newsgroup posting has been automatically converted from an HTML snapshot of the original Python FAQ; please refer to the original "Python FAQ Wizard" at http://grail.cnri.reston.va.us/cgi-bin/faqw.py if source code snippets given in this document do not work - incidentally some formatting information may have been lost during the conversion. ---------------------------------------------------------------------------- The whole Python FAQ - Section 3 Last changed on Mon Jun 28 19:36:09 1999 EDT (Entries marked with ** were changed within the last 24 hours; entries marked with * were changed within the last 7 days.) ---------------------------------------------------------------------------- 3. Building Python and Other Known Bugs 3.1. Is there a test set? 3.2. When running the test set, I get complaints about floating point operations, but when playing with floating point operations I cannot find anything wrong with them. 3.3. Link errors after rerunning the configure script. 3.4. The python interpreter complains about options passed to a script (after the script name). 3.5. When building on the SGI, make tries to run python to create glmodule.c, but python hasn't been built or installed yet. 3.6. I use VPATH but some targets are built in the source directory. 3.7. Trouble building or linking with the GNU readline library. 3.8. Trouble with socket I/O on older Linux 1.x versions. 3.9. Trouble with prototypes on Ultrix. 3.10. Other trouble building Python on platform X. 3.11. How to configure dynamic loading on Linux. 3.12. I can't get shared modules to work on Linux 2.0 (Slackware96)? 3.13. Trouble when making modules shared on Linux. 3.14. How to use threads on Linux. 3.15. Errors when linking with a shared library containing C++ code. 3.16. I built with tkintermodule.c enabled but get 'Tkinter not found' 3.17. I built with Tk 4.0 but Tkinter complains about the Tk version. 3.18. Compilation or link errors for the _tkinter module 3.19. I configured and built Python for Tcl/Tk but "import Tkinter" fails. 3.20. Tk doesn't work right on DEC Alpha. 3.21. Several common system calls are missing from the posix module. 3.22. ImportError: No module named string, on MS Windows. 3.23. Core dump on SGI when using the gl module. 3.24. "Initializer not a constant" while building DLL on MS-Windows 3.25. Output directed to a pipe or file disappears on Linux. 3.26. Syntax Errors all over the place in Linux with libc 5.4 3.27. Crash in XIO on Linux when using Tkinter. 3.28. How can I test if Tkinter is working? 3.29. Is there a way to get the interactive mode of the python interpreter to perform function/variable name completion? 3.30. Why is the Python interpreter not built as a shared library? 3.31. Build with GCC on Solaris 2.6 (SunOS 5.6) fails 3.32. Running "make clean" seems to leave problematic files that cause subsequent builds to fail. ---------------------------------------------------------------------------- 3. Building Python and Other Known Bugs ---------------------------------------------------------------------------- 3.1. Is there a test set? Sure. You can run it after building with "make test", or you can run it manuall with the command import test.autotest In 1.4 or earlier, use import autotest The test set doesn't test all features of Python, but it goes a long way to confirm that Python is actually working. NOTE: if "make test" fails, don't just mail the output to the newsgroup -- this doesn't give enough information to debug the problem. Instead, find out which test fails, and run that test manually from an interactive interpreter. For example, if "make test" reports that test_spam fails, try this interactively: import test.test_spam This generally produces more verbose output which can be diagnosed to debug the problem. ---------------------------------------------------------------------------- 3.2. When running the test set, I get complaints about floating point operations, but when playing with floating point operations I cannot find anything wrong with them. The test set makes occasional unwarranted assumptions about the semantics of C floating point operations. Until someone donates a better floating point test set, you will have to comment out the offending floating point tests and execute similar tests manually. ---------------------------------------------------------------------------- 3.3. Link errors after rerunning the configure script. It is generally necessary to run "make clean" after a configuration change. ---------------------------------------------------------------------------- 3.4. The python interpreter complains about options passed to a script (after the script name). You are probably linking with GNU getopt, e.g. through -liberty. Don't. The reason for the complaint is that GNU getopt, unlike System V getopt and other getopt implementations, doesn't consider a non-option to be the end of the option list. A quick (and compatible) fix for scripts is to add "--" to the interpreter, like this: #! /usr/local/bin/python -- You can also use this interactively: python -- script.py [options] Note that a working getopt implementation is provided in the Python distribution (in Python/getopt.c) but not automatically used. ---------------------------------------------------------------------------- 3.5. When building on the SGI, make tries to run python to create glmodule.c, but python hasn't been built or installed yet. 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.6. I use VPATH but some targets are built in the source directory. On some systems (e.g. Sun), if the target already exists in the source directory, it is created there instead of in the build directory. This is usually because you have previously built without VPATH. Try running "make clobber" in the source directory. ---------------------------------------------------------------------------- 3.7. Trouble building or linking with the GNU readline library. Consider using readline 2.0. Some hints: You can use the GNU readline library to improve the interactive user interface: this gives you line editing and command history when calling python interactively. You need to configure and build the GNU readline library before running the configure script. Its sources are no longer distributed with Python; you can ftp them from any GNU mirror site, or from its home site ftp://slc2.ins.cwru.edu/pub/dist/readline-2.0.tar.gz (or a higher version number -- using version 1.x is not recommended). Pass the Python configure script the option --with-readline=DIRECTORY where DIRECTORY is the absolute pathname of the directory where you've built the readline library. Some hints on building and using the readline library: On SGI IRIX 5, you may have to add the following to rldefs.h: #ifndef sigmask #define sigmask(sig) (1L << ((sig)-1)) #endif On most systems, you will have to add #include "rldefs.h" to the top of several source files, and if you use the VPATH feature, you will have to add dependencies of the form foo.o: foo.c to the Makefile for several values of foo. The readline library requires use of the termcap library. A known problem with this is that it contains entry points which cause conflicts with the STDWIN and SGI GL libraries. The STDWIN conflict can be solved by adding a line saying '#define werase w_erase' to the stdwin.h file (in the STDWIN distribution, subdirectory H). The GL conflict has been solved in the Python configure script by a hack that forces use of the static version of the termcap library. Check the newsgroup gnu.bash.bug news:gnu.bash.bug for specific problems with the readline library (I don't read this group but I've been told that it is the place for readline bugs). ---------------------------------------------------------------------------- 3.8. Trouble with socket I/O on older Linux 1.x versions. Once you've built Python, use it to run the regen.py script in the Lib/linux1 directory. Apparently the files as distributed don't match the system headers on some Linux versions. ---------------------------------------------------------------------------- 3.9. Trouble with prototypes on Ultrix. Ultrix cc seems broken -- use gcc, or edit config.h to #undef HAVE_PROTOTYPES. ---------------------------------------------------------------------------- 3.10. Other trouble building Python on platform X. Please email the details to guido@cnri.reston.va.us and I'll look into it. Please provide as many details as possible. In particular, if you don't tell me what type of computer and what operating system (and version) you are using it will be difficult for me to figure out what is the matter. If you get a specific error message, please email it to me too. ---------------------------------------------------------------------------- 3.11. How to configure dynamic loading on Linux. This is now automatic as long as your Linux version uses the ELF object format (all recent Linuxes do). ---------------------------------------------------------------------------- 3.12. I can't get shared modules to work on Linux 2.0 (Slackware96)? This is a bug in the Slackware96 release. The fix is simple: Make sure that there is a link from /lib/libdl.so to /lib/libdl.so.1 so that the following links are setup: /lib/libdl.so -> /lib/libdl.so.1 /lib/libdl.so.1 -> /lib/libdl.so.1.7.14 You may have to rerun the configure script, after rm'ing the config.cache file, before you attempt to rebuild python after this fix. ---------------------------------------------------------------------------- 3.13. Trouble when making modules shared on Linux. This happens when you have built Python for static linking and then enable *shared* in the Setup file. Shared library code must be compiled with "-fpic". If a .o file for the module already exist that was compiled for static linking, you must remove it or do "make clean" in the Modules directory. ---------------------------------------------------------------------------- 3.14. How to use threads on Linux. [Greg Stein] You need to have a very recent libc, or even better, get the LinuxThreads-0.5 distribution. Note that if you install LinuxThreads normally, then you shouldn't need to specify the directory to the -with-thread configuration switch. The configure script ought to find it without a problem. To make sure everything builds properly, do a "make clean", remove config.cache, re-run configure with that switch, and then build. [Andy Dustman] On glibc systems (i.e. RedHat 5.0+), LinuxThreads is obsoleted by POSIX threads (-lpthread). If you upgraded from an earlier RedHat, remove LinuxThreads with "rpm -e linuxthreads linuxthreads-devel". Then run configure using --with-thread as above. ---------------------------------------------------------------------------- 3.15. Errors when linking with a shared library containing C++ code. Link the main Python binary with C++. Change the definition of LINKCC in Modules/Makefile to be your C++ compiler. You may have to edit config.c slightly to make it compilable with C++. ---------------------------------------------------------------------------- 3.16. I built with tkintermodule.c enabled but get 'Tkinter not found' Tkinter.py (note: upper case T) lives in a subdirectory of Lib, Lib/tkinter. If you are using the default module search path, you probably didn't enable the line in the Modules/Setup file defining TKPATH; if you use the environment variable PYTHONPATH, you'll have to add the proper tkinter subdirectory. For Windows, see question 7.11. ---------------------------------------------------------------------------- 3.17. I built with Tk 4.0 but Tkinter complains about the Tk version. Several things could cause this. You most likely have a Tk 3.6 installation that wasn't completely eradicated by the Tk 4.0 installation (which tends to add "4.0" to its installed files). You may have the Tk 3.6 support library installed in the place where the Tk 4.0 support files should be (default /usr/local/lib/tk/); you may have compiled Python with the old tk.h header file (yes, this actually compiles!); you may actually have linked with Tk 3.6 even though Tk 4.0 is also around. Similar for Tcl 7.4 vs. Tcl 7.3. ---------------------------------------------------------------------------- 3.18. Compilation or link errors for the _tkinter module Most likely, there's a version mismatch between the Tcl/Tk header files (tcl.h and tk.h) and the Tcl/Tk libraries you are using e.g. "-ltk8.0" and "-ltcl8.0" arguments for _tkinter in the Setup file). It is possible to install several versions of the Tcl/Tk libraries, but there can only be one version of the tcl.h and tk.h header files. If the library doesn't match the header, you'll get problems, either when linking the module, or when importing it. Fortunately, the version number is clearly stated in each file, so this is easy to find. Reinstalling and using the latest version usually fixes the problem. (Also note that when compiling unpatched Python 1.5.1 against Tcl/Tk 7.6/4.2 or older, you get an error on Tcl_Finalize. See the 1.5.1 patch page at http://www.python.org/1.5/patches-1.5.1/.) ---------------------------------------------------------------------------- 3.19. I configured and built Python for Tcl/Tk but "import Tkinter" fails. Most likely, you forgot to enable the line in Setup that says "TKPATH=:$(DESTLIB)/tkinter". ---------------------------------------------------------------------------- 3.20. Tk doesn't work right on DEC Alpha. You probably compiled either Tcl, Tk or Python with gcc. Don't. For this platform, which has 64-bit integers, gcc is known to generate broken code. The standard cc (which comes bundled with the OS!) works. If you still prefer gcc, at least try recompiling with cc before reporting problems to the newsgroup or the author; if this fixes the problem, report the bug to the gcc developers instead. (As far as we know, there are no problem with gcc on other platforms -- the instabilities seem to be restricted to the DEC Alpha.) See also question 3.6. There's also a 64-bit bugfix for Tcl/Tk; see http://grail.cnri.reston.va.us/grail/info/patches/tk64bit.txt ---------------------------------------------------------------------------- 3.21. Several common system calls are missing from the posix module. Most likely, all test compilations run by the configure script are failing for some reason or another. Have a look in config.log to see what could be the reason. A common reason is specifying a directory to the --with-readline option that doesn't contain the libreadline.a file. ---------------------------------------------------------------------------- 3.22. ImportError: No module named string, on MS Windows. Most likely, your PYTHONPATH environment variable should be set to something like: set PYTHONPATH=c:\python;c:\python\lib;c:\python\scripts (assuming Python was installed in c:\python) ---------------------------------------------------------------------------- 3.23. Core dump on SGI when using the gl module. There are conflicts between entry points in the termcap and curses libraries and an entry point in the GL library. There's a hack of a fix for the termcap library if it's needed for the GNU readline library, but it doesn't work when you're using curses. Concluding, you can't build a Python binary containing both the curses and gl modules. ---------------------------------------------------------------------------- 3.24. "Initializer not a constant" while building DLL on MS-Windows Static type object initializers in extension modules may cause compiles to fail with an error message like "initializer not a constant". Fredrik Lundh explains: This shows up when building DLL under MSVC. There's two ways to address this: either compile the module as C++, or change your code to something like: statichere PyTypeObject bstreamtype = { PyObject_HEAD_INIT(NULL) /* must be set by init function */ 0, "bstream", sizeof(bstreamobject), ... void initbstream() { /* Patch object type */ bstreamtype.ob_type = &PyType_Type; Py_InitModule("bstream", functions); ... } ---------------------------------------------------------------------------- 3.25. Output directed to a pipe or file disappears on Linux. Some people have reported that when they run their script interactively, it runs great, but that when they redirect it to a pipe or file, no output appears. % python script.py ...some output... % python script.py >file % cat file % # no output % python script.py | cat % # no output % Nobody knows what causes this, but it is apparently a Linux bug. Most Linux users are not affected by this. There's at least one report of someone who reinstalled Linux (presumably a newer version) and Python and got rid of the problem; so this may be the solution. ---------------------------------------------------------------------------- 3.26. Syntax Errors all over the place in Linux with libc 5.4 ``I have installed python1.4 on my Linux system. When I try run the import statement I get the following error message:'' File "<stdin>", line 1 import sys ^ Syntax Error: "invalid syntax" Did you compile it yourself? This usually is caused by an incompatibility between libc 5.4.x and earlier libc's. In particular, programs compiled with libc 5.4 give incorrect results on systems which had libc 5.2 installed because the ctype.h file is broken. In this case, Python can't recognize which characters are letters and so on. The fix is to install the C library which was used when building the binary that you installed, or to compile Python yourself. When you do this, make sure the C library header files which get used by the compiler match the installed C library. [adapted from an answer by Martin v. Loewis] PS [adapted from Andreas Jung]: If you have upgraded to libc 5.4.x, and the problem persists, check your library path for an older version of libc. Try to clean update libc with the libs and the header files and then try to recompile all. ---------------------------------------------------------------------------- 3.27. Crash in XIO on Linux when using Tkinter. When Python is built with threads under Linux, use of Tkinter can cause crashes like the following: >>> from Tkinter import * >>> root = Tk() XIO: fatal IO error 0 (Unknown error) on X server ":0.0" after 45 requests (40 known processed) with 1 events remaining. The reason is that the default Xlib is not built with support for threads. If you rebuild Xlib with threads enabled the problems go away. Alternatively, you can rebuild Python without threads ("make clean" first!). (Disclaimer: this is from memory.) ---------------------------------------------------------------------------- 3.28. How can I test if Tkinter is working? Try the following: python >>> import _tkinter >>> import Tkinter >>> Tkinter._test() This should pop up a window with two buttons, one "Click me" and one "Quit". If the first statement (import _tkinter) fails, your Python installation probably has not been configured to support Tcl/Tk. On Unix, if you have installed Tcl/Tk, you have to rebuild Python after editing the Modules/Setup file to enable the _tkinter module and the TKPATH environment variable. It is also possible to get complaints about Tcl/Tk version number mismatches or missing TCL_LIBRARY or TK_LIBRARY environment variables. These have to do with Tcl/Tk installation problems. A common problem is to have installed versions of tcl.h and tk.h that don't match the installed version of the Tcl/Tk libraries; this usually results in linker errors or (when using dynamic loading) complaints about missing symbols during loading the shared library. ---------------------------------------------------------------------------- 3.29. Is there a way to get the interactive mode of the python interpreter to perform function/variable name completion? (From a posting by Guido van Rossum) On Unix, if you have enabled the readline module (i.e. if Emacs-style command line editing and bash-style history works for you), you can add this by importing the undocumented standard library module "rlcompleter". When completing a simple identifier, it completes keywords, built-ins and globals in __main__; when completing NAME.NAME..., it evaluates (!) the expression up to the last dot and completes its attributes. This way, you can do "import string", type "string.", hit the completion key twice, and see the list of names defined by the string module. Tip: to use the tab key as the completion key, call readline.parse_and_bind("tab: complete") You can put this in a ~/.pythonrc file, and set the PYTHONSTARTUP environment variable to ~/.pythonrc. This will cause the completion to be enabled whenever you run Python interactively. Notes (see the docstring for rlcompleter.py for more information): * The evaluation of the NAME.NAME... form may cause arbitrary application defined code to be executed if an object with a __getattr__ hook is found. Since it is the responsibility of the application (or the user) to enable this feature, I consider this an acceptable risk. More complicated expressions (e.g. function calls or indexing operations) are not evaluated. * GNU readline is also used by the built-in functions input() and raw_input(), and thus these also benefit/suffer from the complete features. Clearly an interactive application can benefit by specifying its own completer function and using raw_input() for all its input. * When stdin is not a tty device, GNU readline is never used, and this module (and the readline module) are silently inactive. ---------------------------------------------------------------------------- 3.30. Why is the Python interpreter not built as a shared library? (This is a Unix question; on Mac and Windows, it is a shared library.) It's just a nightmare to get this to work on all different platforms. Shared library portability is a pain. And yes, I know about GNU libtool -- but it requires me to use its conventions for filenames etc, and it would require a complete and utter rewrite of all the makefile and config tools I'm currently using. In practice, few applications embed Python -- it's much more common to have Python extensions, which already are shared libraries. Also, serious embedders often want total control over which Python version and configuration they use so they wouldn't want to use a standard shared library anyway. So while the motivation of saving space when lots of apps embed Python is nice in theory, I doubt that it will save much in practice. (Hence the low priority I give to making a shared library.) ---------------------------------------------------------------------------- 3.31. Build with GCC on Solaris 2.6 (SunOS 5.6) fails If you have upgraded Solaris 2.5 or 2.5.1 to Solaris 2.6, but you have not upgraded your GCC installation, the compile may fail, e.g. like this: In file included from /usr/include/sys/stream.h:26, from /usr/include/netinet/in.h:38, from /usr/include/netdb.h:96, from ./socketmodule.c:121: /usr/include/sys/model.h:32: #error "No DATAMODEL_NATIVE specified" Solution: rebuild GCC for Solaris 2.6. You might be able to simply re-run fixincludes, but people have had mixed success with doing that. ---------------------------------------------------------------------------- 3.32. Running "make clean" seems to leave problematic files that cause subsequent builds to fail. Use "make clobber" instead. Use "make clean" to reduce the size of the source/build directory after you're happy with your build and installation. If you have already tried to build python and you'd like to start over, you should use "make clobber". It does a "make clean" and also removes files such as the partially built Python library from a previous build. ---------------------------------------------------------------------------- -- ----------- comp.lang.python.announce (moderated) ---------- Article Submission Address: python-announce@python.org Python Language Home Page: http://www.python.org/ Python Quick Help Index: http://www.python.org/Help.html ------------------------------------------------------------