Python Language FAQ - Section 3
Markus Fleck
python-announce@python.org
Wed, 07 Jul 99 23:27:23 GMT
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
<Fredrik.Lundh@image.combitech.se> 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
------------------------------------------------------------