]>
Commit | Line | Data |
---|---|---|
4710c53d | 1 | This is Python version 2.7.2\r |
2 | ============================\r | |
3 | \r | |
4 | Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011\r | |
5 | Python Software Foundation. All rights reserved.\r | |
6 | \r | |
7 | Copyright (c) 2000 BeOpen.com.\r | |
8 | All rights reserved.\r | |
9 | \r | |
10 | Copyright (c) 1995-2001 Corporation for National Research Initiatives.\r | |
11 | All rights reserved.\r | |
12 | \r | |
13 | Copyright (c) 1991-1995 Stichting Mathematisch Centrum.\r | |
14 | All rights reserved.\r | |
15 | \r | |
16 | \r | |
17 | License information\r | |
18 | -------------------\r | |
19 | \r | |
20 | See the file "LICENSE" for information on the history of this\r | |
21 | software, terms & conditions for usage, and a DISCLAIMER OF ALL\r | |
22 | WARRANTIES.\r | |
23 | \r | |
24 | This Python distribution contains no GNU General Public Licensed\r | |
25 | (GPLed) code so it may be used in proprietary projects just like prior\r | |
26 | Python distributions. There are interfaces to some GNU code but these\r | |
27 | are entirely optional.\r | |
28 | \r | |
29 | All trademarks referenced herein are property of their respective\r | |
30 | holders.\r | |
31 | \r | |
32 | \r | |
33 | What's new in this release?\r | |
34 | ---------------------------\r | |
35 | \r | |
36 | See the file "Misc/NEWS".\r | |
37 | \r | |
38 | \r | |
39 | If you don't read instructions\r | |
40 | ------------------------------\r | |
41 | \r | |
42 | Congratulations on getting this far. :-)\r | |
43 | \r | |
44 | To start building right away (on UNIX): type "./configure" in the\r | |
45 | current directory and when it finishes, type "make". This creates an\r | |
46 | executable "./python"; to install in /usr/local, first do "su root"\r | |
47 | and then "make install".\r | |
48 | \r | |
49 | The section `Build instructions' below is still recommended reading.\r | |
50 | \r | |
51 | \r | |
52 | What is Python anyway?\r | |
53 | ----------------------\r | |
54 | \r | |
55 | Python is an interpreted, interactive object-oriented programming\r | |
56 | language suitable (amongst other uses) for distributed application\r | |
57 | development, scripting, numeric computing and system testing. Python\r | |
58 | is often compared to Tcl, Perl, Java, JavaScript, Visual Basic or\r | |
59 | Scheme. To find out more about what Python can do for you, point your\r | |
60 | browser to http://www.python.org/.\r | |
61 | \r | |
62 | \r | |
63 | How do I learn Python?\r | |
64 | ----------------------\r | |
65 | \r | |
66 | The official tutorial is still a good place to start; see\r | |
67 | http://docs.python.org/ for online and downloadable versions, as well\r | |
68 | as a list of other introductions, and reference documentation.\r | |
69 | \r | |
70 | There's a quickly growing set of books on Python. See\r | |
71 | http://wiki.python.org/moin/PythonBooks for a list.\r | |
72 | \r | |
73 | \r | |
74 | Documentation\r | |
75 | -------------\r | |
76 | \r | |
77 | All documentation is provided online in a variety of formats. In\r | |
78 | order of importance for new users: Tutorial, Library Reference,\r | |
79 | Language Reference, Extending & Embedding, and the Python/C API. The\r | |
80 | Library Reference is especially of immense value since much of\r | |
81 | Python's power is described there, including the built-in data types\r | |
82 | and functions!\r | |
83 | \r | |
84 | All documentation is also available online at the Python web site\r | |
85 | (http://docs.python.org/, see below). It is available online for occasional\r | |
86 | reference, or can be downloaded in many formats for faster access. The\r | |
87 | documentation is downloadable in HTML, PostScript, PDF, LaTeX, and\r | |
88 | reStructuredText (2.6+) formats; the LaTeX and reStructuredText versions are\r | |
89 | primarily for documentation authors, translators, and people with special\r | |
90 | formatting requirements.\r | |
91 | \r | |
92 | \r | |
93 | Web sites\r | |
94 | ---------\r | |
95 | \r | |
96 | New Python releases and related technologies are published at\r | |
97 | http://www.python.org/. Come visit us!\r | |
98 | \r | |
99 | \r | |
100 | Newsgroups and Mailing Lists\r | |
101 | ----------------------------\r | |
102 | \r | |
103 | Read comp.lang.python, a high-volume discussion newsgroup about\r | |
104 | Python, or comp.lang.python.announce, a low-volume moderated newsgroup\r | |
105 | for Python-related announcements. These are also accessible as\r | |
106 | mailing lists: see http://www.python.org/community/lists/ for an\r | |
107 | overview of these and many other Python-related mailing lists.\r | |
108 | \r | |
109 | Archives are accessible via the Google Groups Usenet archive; see\r | |
110 | http://groups.google.com/. The mailing lists are also archived, see\r | |
111 | http://www.python.org/community/lists/ for details.\r | |
112 | \r | |
113 | \r | |
114 | Bug reports\r | |
115 | -----------\r | |
116 | \r | |
117 | To report or search for bugs, please use the Python Bug\r | |
118 | Tracker at http://bugs.python.org/.\r | |
119 | \r | |
120 | \r | |
121 | Patches and contributions\r | |
122 | -------------------------\r | |
123 | \r | |
124 | To submit a patch or other contribution, please use the Python Patch\r | |
125 | Manager at http://bugs.python.org/. Guidelines\r | |
126 | for patch submission may be found at http://www.python.org/dev/patches/.\r | |
127 | \r | |
128 | If you have a proposal to change Python, you may want to send an email to the\r | |
129 | comp.lang.python or python-ideas mailing lists for inital feedback. A Python\r | |
130 | Enhancement Proposal (PEP) may be submitted if your idea gains ground. All\r | |
131 | current PEPs, as well as guidelines for submitting a new PEP, are listed at\r | |
132 | http://www.python.org/dev/peps/.\r | |
133 | \r | |
134 | \r | |
135 | Questions\r | |
136 | ---------\r | |
137 | \r | |
138 | For help, if you can't find it in the manuals or on the web site, it's\r | |
139 | best to post to the comp.lang.python or the Python mailing list (see\r | |
140 | above). If you specifically don't want to involve the newsgroup or\r | |
141 | mailing list, send questions to help@python.org (a group of volunteers\r | |
142 | who answer questions as they can). The newsgroup is the most\r | |
143 | efficient way to ask public questions.\r | |
144 | \r | |
145 | \r | |
146 | Build instructions\r | |
147 | ==================\r | |
148 | \r | |
149 | Before you can build Python, you must first configure it.\r | |
150 | Fortunately, the configuration and build process has been automated\r | |
151 | for Unix and Linux installations, so all you usually have to do is\r | |
152 | type a few commands and sit back. There are some platforms where\r | |
153 | things are not quite as smooth; see the platform specific notes below.\r | |
154 | If you want to build for multiple platforms sharing the same source\r | |
155 | tree, see the section on VPATH below.\r | |
156 | \r | |
157 | Start by running the script "./configure", which determines your\r | |
158 | system configuration and creates the Makefile. (It takes a minute or\r | |
159 | two -- please be patient!) You may want to pass options to the\r | |
160 | configure script -- see the section below on configuration options and\r | |
161 | variables. When it's done, you are ready to run make.\r | |
162 | \r | |
163 | To build Python, you normally type "make" in the toplevel directory.\r | |
164 | If you have changed the configuration, the Makefile may have to be\r | |
165 | rebuilt. In this case, you may have to run make again to correctly\r | |
166 | build your desired target. The interpreter executable is built in the\r | |
167 | top level directory.\r | |
168 | \r | |
169 | Once you have built a Python interpreter, see the subsections below on\r | |
170 | testing and installation. If you run into trouble, see the next\r | |
171 | section.\r | |
172 | \r | |
173 | Previous versions of Python used a manual configuration process that\r | |
174 | involved editing the file Modules/Setup. While this file still exists\r | |
175 | and manual configuration is still supported, it is rarely needed any\r | |
176 | more: almost all modules are automatically built as appropriate under\r | |
177 | guidance of the setup.py script, which is run by Make after the\r | |
178 | interpreter has been built.\r | |
179 | \r | |
180 | \r | |
181 | Troubleshooting\r | |
182 | ---------------\r | |
183 | \r | |
184 | See also the platform specific notes in the next section.\r | |
185 | \r | |
186 | If you run into other trouble, see the FAQ\r | |
187 | (http://www.python.org/doc/faq/) for hints on what can go wrong, and\r | |
188 | how to fix it.\r | |
189 | \r | |
190 | If you rerun the configure script with different options, remove all\r | |
191 | object files by running "make clean" before rebuilding. Believe it or\r | |
192 | not, "make clean" sometimes helps to clean up other inexplicable\r | |
193 | problems as well. Try it before sending in a bug report!\r | |
194 | \r | |
195 | If the configure script fails or doesn't seem to find things that\r | |
196 | should be there, inspect the config.log file.\r | |
197 | \r | |
198 | If you get a warning for every file about the -Olimit option being no\r | |
199 | longer supported, you can ignore it. There's no foolproof way to know\r | |
200 | whether this option is needed; all we can do is test whether it is\r | |
201 | accepted without error. On some systems, e.g. older SGI compilers, it\r | |
202 | is essential for performance (specifically when compiling ceval.c,\r | |
203 | which has more basic blocks than the default limit of 1000). If the\r | |
204 | warning bothers you, edit the Makefile to remove "-Olimit 1500" from\r | |
205 | the OPT variable.\r | |
206 | \r | |
207 | If you get failures in test_long, or sys.maxint gets set to -1, you\r | |
208 | are probably experiencing compiler bugs, usually related to\r | |
209 | optimization. This is a common problem with some versions of gcc, and\r | |
210 | some vendor-supplied compilers, which can sometimes be worked around\r | |
211 | by turning off optimization. Consider switching to stable versions\r | |
212 | (gcc 2.95.2, gcc 3.x, or contact your vendor.)\r | |
213 | \r | |
214 | From Python 2.0 onward, all Python C code is ANSI C. Compiling using\r | |
215 | old K&R-C-only compilers is no longer possible. ANSI C compilers are\r | |
216 | available for all modern systems, either in the form of updated\r | |
217 | compilers from the vendor, or one of the free compilers (gcc).\r | |
218 | \r | |
219 | If "make install" fails mysteriously during the "compiling the library"\r | |
220 | step, make sure that you don't have any of the PYTHONPATH or PYTHONHOME\r | |
221 | environment variables set, as they may interfere with the newly built\r | |
222 | executable which is compiling the library.\r | |
223 | \r | |
224 | Unsupported systems\r | |
225 | -------------------\r | |
226 | \r | |
227 | A number of systems are not supported in Python 2.7 anymore. Some\r | |
228 | support code is still present, but will be removed in later versions.\r | |
229 | If you still need to use current Python versions on these systems,\r | |
230 | please send a message to python-dev@python.org indicating that you\r | |
231 | volunteer to support this system. For a more detailed discussion \r | |
232 | regarding no-longer-supported and resupporting platforms, as well\r | |
233 | as a list of platforms that became or will be unsupported, see PEP 11.\r | |
234 | \r | |
235 | More specifically, the following systems are not supported any\r | |
236 | longer:\r | |
237 | - SunOS 4\r | |
238 | - DYNIX\r | |
239 | - dgux\r | |
240 | - Minix\r | |
241 | - NeXT\r | |
242 | - Irix 4 and --with-sgi-dl\r | |
243 | - Linux 1\r | |
244 | - Systems defining __d6_pthread_create (configure.in)\r | |
245 | - Systems defining PY_PTHREAD_D4, PY_PTHREAD_D6,\r | |
246 | or PY_PTHREAD_D7 in thread_pthread.h\r | |
247 | - Systems using --with-dl-dld\r | |
248 | - Systems using --without-universal-newlines\r | |
249 | - MacOS 9\r | |
250 | - Systems using --with-wctype-functions\r | |
251 | - Win9x, WinME\r | |
252 | \r | |
253 | \r | |
254 | Platform specific notes\r | |
255 | -----------------------\r | |
256 | \r | |
257 | (Some of these may no longer apply. If you find you can build Python\r | |
258 | on these platforms without the special directions mentioned here,\r | |
259 | submit a documentation bug report to SourceForge (see Bug Reports\r | |
260 | above) so we can remove them!)\r | |
261 | \r | |
262 | Unix platforms: If your vendor still ships (and you still use) Berkeley DB\r | |
263 | 1.85 you will need to edit Modules/Setup to build the bsddb185\r | |
264 | module and add a line to sitecustomize.py which makes it the\r | |
265 | default. In Modules/Setup a line like\r | |
266 | \r | |
267 | bsddb185 bsddbmodule.c\r | |
268 | \r | |
269 | should work. (You may need to add -I, -L or -l flags to direct the\r | |
270 | compiler and linker to your include files and libraries.)\r | |
271 | \r | |
272 | XXX I think this next bit is out of date:\r | |
273 | \r | |
274 | 64-bit platforms: The modules audioop, and imageop don't work.\r | |
275 | The setup.py script disables them on 64-bit installations.\r | |
276 | Don't try to enable them in the Modules/Setup file. They\r | |
277 | contain code that is quite wordsize sensitive. (If you have a\r | |
278 | fix, let us know!)\r | |
279 | \r | |
280 | Solaris: When using Sun's C compiler with threads, at least on Solaris\r | |
281 | 2.5.1, you need to add the "-mt" compiler option (the simplest\r | |
282 | way is probably to specify the compiler with this option as\r | |
283 | the "CC" environment variable when running the configure\r | |
284 | script).\r | |
285 | \r | |
286 | When using GCC on Solaris, beware of binutils 2.13 or GCC\r | |
287 | versions built using it. This mistakenly enables the\r | |
288 | -zcombreloc option which creates broken shared libraries on\r | |
289 | Solaris. binutils 2.12 works, and the binutils maintainers\r | |
290 | are aware of the problem. Binutils 2.13.1 only partially\r | |
291 | fixed things. It appears that 2.13.2 solves the problem\r | |
292 | completely. This problem is known to occur with Solaris 2.7\r | |
293 | and 2.8, but may also affect earlier and later versions of the\r | |
294 | OS.\r | |
295 | \r | |
296 | When the dynamic loader complains about errors finding shared\r | |
297 | libraries, such as\r | |
298 | \r | |
299 | ld.so.1: ./python: fatal: libstdc++.so.5: open failed:\r | |
300 | No such file or directory\r | |
301 | \r | |
302 | you need to first make sure that the library is available on\r | |
303 | your system. Then, you need to instruct the dynamic loader how\r | |
304 | to find it. You can choose any of the following strategies:\r | |
305 | \r | |
306 | 1. When compiling Python, set LD_RUN_PATH to the directories\r | |
307 | containing missing libraries.\r | |
308 | 2. When running Python, set LD_LIBRARY_PATH to these directories.\r | |
309 | 3. Use crle(8) to extend the search path of the loader.\r | |
310 | 4. Modify the installed GCC specs file, adding -R options into the\r | |
311 | *link: section.\r | |
312 | \r | |
313 | The complex object fails to compile on Solaris 10 with gcc 3.4 (at\r | |
314 | least up to 3.4.3). To work around it, define Py_HUGE_VAL as\r | |
315 | HUGE_VAL(), e.g.:\r | |
316 | \r | |
317 | make CPPFLAGS='-D"Py_HUGE_VAL=HUGE_VAL()" -I. -I$(srcdir)/Include'\r | |
318 | ./python setup.py CPPFLAGS='-D"Py_HUGE_VAL=HUGE_VAL()"'\r | |
319 | \r | |
320 | Linux: A problem with threads and fork() was tracked down to a bug in\r | |
321 | the pthreads code in glibc version 2.0.5; glibc version 2.0.7\r | |
322 | solves the problem. This causes the popen2 test to fail;\r | |
323 | problem and solution reported by Pablo Bleyer.\r | |
324 | \r | |
325 | Red Hat Linux: Red Hat 9 built Python2.2 in UCS-4 mode and hacked\r | |
326 | Tcl to support it. To compile Python2.3 with Tkinter, you will\r | |
327 | need to pass --enable-unicode=ucs4 flag to ./configure.\r | |
328 | \r | |
329 | There's an executable /usr/bin/python which is Python\r | |
330 | 1.5.2 on most older Red Hat installations; several key Red Hat tools\r | |
331 | require this version. Python 2.1.x may be installed as\r | |
332 | /usr/bin/python2. The Makefile installs Python as\r | |
333 | /usr/local/bin/python, which may or may not take precedence\r | |
334 | over /usr/bin/python, depending on how you have set up $PATH.\r | |
335 | \r | |
336 | FreeBSD 3.x and probably platforms with NCurses that use libmytinfo or\r | |
337 | similar: When using cursesmodule, the linking is not done in\r | |
338 | the correct order with the defaults. Remove "-ltermcap" from\r | |
339 | the readline entry in Setup, and use as curses entry: "curses\r | |
340 | cursesmodule.c -lmytinfo -lncurses -ltermcap" - "mytinfo" (so\r | |
341 | called on FreeBSD) should be the name of the auxiliary library\r | |
342 | required on your platform. Normally, it would be linked\r | |
343 | automatically, but not necessarily in the correct order.\r | |
344 | \r | |
345 | BSDI: BSDI versions before 4.1 have known problems with threads,\r | |
346 | which can cause strange errors in a number of modules (for\r | |
347 | instance, the 'test_signal' test script will hang forever.)\r | |
348 | Turning off threads (with --with-threads=no) or upgrading to\r | |
349 | BSDI 4.1 solves this problem.\r | |
350 | \r | |
351 | DEC Unix: Run configure with --with-dec-threads, or with\r | |
352 | --with-threads=no if no threads are desired (threads are on by\r | |
353 | default). When using GCC, it is possible to get an internal\r | |
354 | compiler error if optimization is used. This was reported for\r | |
355 | GCC 2.7.2.3 on selectmodule.c. Manually compile the affected\r | |
356 | file without optimization to solve the problem.\r | |
357 | \r | |
358 | DEC Ultrix: compile with GCC to avoid bugs in the native compiler,\r | |
359 | and pass SHELL=/bin/sh5 to Make when installing.\r | |
360 | \r | |
361 | AIX: A complete overhaul of the shared library support is now in\r | |
362 | place. See Misc/AIX-NOTES for some notes on how it's done.\r | |
363 | (The optimizer bug reported at this place in previous releases\r | |
364 | has been worked around by a minimal code change.) If you get\r | |
365 | errors about pthread_* functions, during compile or during\r | |
366 | testing, try setting CC to a thread-safe (reentrant) compiler,\r | |
367 | like "cc_r". For full C++ module support, set CC="xlC_r" (or\r | |
368 | CC="xlC" without thread support).\r | |
369 | \r | |
370 | AIX 5.3: To build a 64-bit version with IBM's compiler, I used the\r | |
371 | following:\r | |
372 | \r | |
373 | export PATH=/usr/bin:/usr/vacpp/bin\r | |
374 | ./configure --with-gcc="xlc_r -q64" --with-cxx="xlC_r -q64" \\r | |
375 | --disable-ipv6 AR="ar -X64"\r | |
376 | make\r | |
377 | \r | |
378 | HP-UX: When using threading, you may have to add -D_REENTRANT to the\r | |
379 | OPT variable in the top-level Makefile; reported by Pat Knight,\r | |
380 | this seems to make a difference (at least for HP-UX 10.20)\r | |
381 | even though pyconfig.h defines it. This seems unnecessary when\r | |
382 | using HP/UX 11 and later - threading seems to work "out of the\r | |
383 | box".\r | |
384 | \r | |
385 | HP-UX ia64: When building on the ia64 (Itanium) platform using HP's\r | |
386 | compiler, some experience has shown that the compiler's\r | |
387 | optimiser produces a completely broken version of python\r | |
388 | (see http://bugs.python.org/814976). To work around this,\r | |
389 | edit the Makefile and remove -O from the OPT line.\r | |
390 | \r | |
391 | To build a 64-bit executable on an Itanium 2 system using HP's\r | |
392 | compiler, use these environment variables:\r | |
393 | \r | |
394 | CC=cc\r | |
395 | CXX=aCC\r | |
396 | BASECFLAGS="+DD64"\r | |
397 | LDFLAGS="+DD64 -lxnet"\r | |
398 | \r | |
399 | and call configure as:\r | |
400 | \r | |
401 | ./configure --without-gcc\r | |
402 | \r | |
403 | then *unset* the environment variables again before running\r | |
404 | make. (At least one of these flags causes the build to fail\r | |
405 | if it remains set.) You still have to edit the Makefile and\r | |
406 | remove -O from the OPT line.\r | |
407 | \r | |
408 | HP PA-RISC 2.0: A recent bug report (http://bugs.python.org/546117)\r | |
409 | suggests that the C compiler in this 64-bit system has bugs\r | |
410 | in the optimizer that break Python. Compiling without\r | |
411 | optimization solves the problems.\r | |
412 | \r | |
413 | SCO: The following apply to SCO 3 only; Python builds out of the box\r | |
414 | on SCO 5 (or so we've heard).\r | |
415 | \r | |
416 | 1) Everything works much better if you add -U__STDC__ to the\r | |
417 | defs. This is because all the SCO header files are broken.\r | |
418 | Anything that isn't mentioned in the C standard is\r | |
419 | conditionally excluded when __STDC__ is defined.\r | |
420 | \r | |
421 | 2) Due to the U.S. export restrictions, SCO broke the crypt\r | |
422 | stuff out into a separate library, libcrypt_i.a so the LIBS\r | |
423 | needed be set to:\r | |
424 | \r | |
425 | LIBS=' -lsocket -lcrypt_i'\r | |
426 | \r | |
427 | UnixWare: There are known bugs in the math library of the system, as well as\r | |
428 | problems in the handling of threads (calling fork in one\r | |
429 | thread may interrupt system calls in others). Therefore, test_math and\r | |
430 | tests involving threads will fail until those problems are fixed.\r | |
431 | \r | |
432 | QNX: Chris Herborth (chrish@qnx.com) writes:\r | |
433 | configure works best if you use GNU bash; a port is available on\r | |
434 | ftp.qnx.com in /usr/free. I used the following process to build,\r | |
435 | test and install Python 1.5.x under QNX:\r | |
436 | \r | |
437 | 1) CONFIG_SHELL=/usr/local/bin/bash CC=cc RANLIB=: \\r | |
438 | ./configure --verbose --without-gcc --with-libm=""\r | |
439 | \r | |
440 | 2) edit Modules/Setup to activate everything that makes sense for\r | |
441 | your system... tested here at QNX with the following modules:\r | |
442 | \r | |
443 | array, audioop, binascii, cPickle, cStringIO, cmath,\r | |
444 | crypt, curses, errno, fcntl, gdbm, grp, imageop,\r | |
445 | _locale, math, md5, new, operator, parser, pcre,\r | |
446 | posix, pwd, readline, regex, reop,\r | |
447 | select, signal, socket, soundex, strop, struct,\r | |
448 | syslog, termios, time, timing, zlib, audioop, imageop\r | |
449 | \r | |
450 | 3) make SHELL=/usr/local/bin/bash\r | |
451 | \r | |
452 | or, if you feel the need for speed:\r | |
453 | \r | |
454 | make SHELL=/usr/local/bin/bash OPT="-5 -Oil+nrt"\r | |
455 | \r | |
456 | 4) make SHELL=/usr/local/bin/bash test\r | |
457 | \r | |
458 | Using GNU readline 2.2 seems to behave strangely, but I\r | |
459 | think that's a problem with my readline 2.2 port. :-\\r | |
460 | \r | |
461 | 5) make SHELL=/usr/local/bin/bash install\r | |
462 | \r | |
463 | If you get SIGSEGVs while running Python (I haven't yet, but\r | |
464 | I've only run small programs and the test cases), you're\r | |
465 | probably running out of stack; the default 32k could be a\r | |
466 | little tight. To increase the stack size, edit the Makefile\r | |
467 | to read: LDFLAGS = -N 48k\r | |
468 | \r | |
469 | BeOS: See Misc/BeOS-NOTES for notes about compiling/installing\r | |
470 | Python on BeOS R3 or later. Note that only the PowerPC\r | |
471 | platform is supported for R3; both PowerPC and x86 are\r | |
472 | supported for R4.\r | |
473 | \r | |
474 | Cray T3E: Mark Hadfield (m.hadfield@niwa.co.nz) writes:\r | |
475 | Python can be built satisfactorily on a Cray T3E but based on\r | |
476 | my experience with the NIWA T3E (2002-05-22, version 2.2.1)\r | |
477 | there are a few bugs and gotchas. For more information see a\r | |
478 | thread on comp.lang.python in May 2002 entitled "Building\r | |
479 | Python on Cray T3E".\r | |
480 | \r | |
481 | 1) Use Cray's cc and not gcc. The latter was reported not to\r | |
482 | work by Konrad Hinsen. It may work now, but it may not.\r | |
483 | \r | |
484 | 2) To set sys.platform to something sensible, pass the\r | |
485 | following environment variable to the configure script:\r | |
486 | \r | |
487 | MACHDEP=unicosmk\r | |
488 | \r | |
489 | 2) Run configure with option "--enable-unicode=ucs4".\r | |
490 | \r | |
491 | 3) The Cray T3E does not support dynamic linking, so extension\r | |
492 | modules have to be built by adding (or uncommenting) lines\r | |
493 | in Modules/Setup. The minimum set of modules is\r | |
494 | \r | |
495 | posix, new, _sre, unicodedata\r | |
496 | \r | |
497 | On NIWA's vanilla T3E system the following have also been\r | |
498 | included successfully:\r | |
499 | \r | |
500 | _codecs, _locale, _socket, _symtable, _testcapi, _weakref\r | |
501 | array, binascii, cmath, cPickle, crypt, cStringIO, dbm\r | |
502 | errno, fcntl, grp, math, md5, operator, parser, pcre, pwd\r | |
503 | regex, rotor, select, struct, strop, syslog, termios\r | |
504 | time, timing, xreadlines\r | |
505 | \r | |
506 | 4) Once the python executable and library have been built, make\r | |
507 | will execute setup.py, which will attempt to build remaining\r | |
508 | extensions and link them dynamically. Each of these attempts\r | |
509 | will fail but should not halt the make process. This is\r | |
510 | normal.\r | |
511 | \r | |
512 | 5) Running "make test" uses a lot of resources and causes\r | |
513 | problems on our system. You might want to try running tests\r | |
514 | singly or in small groups.\r | |
515 | \r | |
516 | SGI: SGI's standard "make" utility (/bin/make or /usr/bin/make)\r | |
517 | does not check whether a command actually changed the file it\r | |
518 | is supposed to build. This means that whenever you say "make"\r | |
519 | it will redo the link step. The remedy is to use SGI's much\r | |
520 | smarter "smake" utility (/usr/sbin/smake), or GNU make. If\r | |
521 | you set the first line of the Makefile to #!/usr/sbin/smake\r | |
522 | smake will be invoked by make (likewise for GNU make).\r | |
523 | \r | |
524 | WARNING: There are bugs in the optimizer of some versions of\r | |
525 | SGI's compilers that can cause bus errors or other strange\r | |
526 | behavior, especially on numerical operations. To avoid this,\r | |
527 | try building with "make OPT=".\r | |
528 | \r | |
529 | OS/2: If you are running Warp3 or Warp4 and have IBM's VisualAge C/C++\r | |
530 | compiler installed, just change into the pc\os2vacpp directory\r | |
531 | and type NMAKE. Threading and sockets are supported by default\r | |
532 | in the resulting binaries of PYTHON15.DLL and PYTHON.EXE.\r | |
533 | \r | |
534 | Reliant UNIX: The thread support does not compile on Reliant UNIX, and\r | |
535 | there is a (minor) problem in the configure script for that\r | |
536 | platform as well. This should be resolved in time for a\r | |
537 | future release.\r | |
538 | \r | |
539 | MacOSX: The tests will crash on both 10.1 and 10.2 with SEGV in\r | |
540 | test_re and test_sre due to the small default stack size. If\r | |
541 | you set the stack size to 2048 before doing a "make test" the\r | |
542 | failure can be avoided. If you're using the tcsh or csh shells,\r | |
543 | use "limit stacksize 2048" and for the bash shell (the default\r | |
544 | as of OSX 10.3), use "ulimit -s 2048".\r | |
545 | \r | |
546 | On naked Darwin you may want to add the configure option\r | |
547 | "--disable-toolbox-glue" to disable the glue code for the Carbon\r | |
548 | interface modules. The modules themselves are currently only built\r | |
549 | if you add the --enable-framework option, see below.\r | |
550 | \r | |
551 | On a clean OSX /usr/local does not exist. Do a\r | |
552 | "sudo mkdir -m 775 /usr/local"\r | |
553 | before you do a make install. It is probably not a good idea to\r | |
554 | do "sudo make install" which installs everything as superuser,\r | |
555 | as this may later cause problems when installing distutils-based\r | |
556 | additions.\r | |
557 | \r | |
558 | Some people have reported problems building Python after using "fink"\r | |
559 | to install additional unix software. Disabling fink (remove all \r | |
560 | references to /sw from your .profile or .login) should solve this.\r | |
561 | \r | |
562 | You may want to try the configure option "--enable-framework"\r | |
563 | which installs Python as a framework. The location can be set\r | |
564 | as argument to the --enable-framework option (default\r | |
565 | /Library/Frameworks). A framework install is probably needed if you\r | |
566 | want to use any Aqua-based GUI toolkit (whether Tkinter, wxPython,\r | |
567 | Carbon, Cocoa or anything else).\r | |
568 | \r | |
569 | You may also want to try the configure option "--enable-universalsdk"\r | |
570 | which builds Python as a universal binary with support for the \r | |
571 | i386 and PPC architetures. This requires Xcode 2.1 or later to build.\r | |
572 | \r | |
573 | See Mac/README for more information on framework and \r | |
574 | universal builds.\r | |
575 | \r | |
576 | Cygwin: With recent (relative to the time of writing, 2001-12-19)\r | |
577 | Cygwin installations, there are problems with the interaction\r | |
578 | of dynamic linking and fork(). This manifests itself in build\r | |
579 | failures during the execution of setup.py.\r | |
580 | \r | |
581 | There are two workarounds that both enable Python (albeit\r | |
582 | without threading support) to build and pass all tests on\r | |
583 | NT/2000 (and most likely XP as well, though reports of testing\r | |
584 | on XP would be appreciated).\r | |
585 | \r | |
586 | The workarounds:\r | |
587 | \r | |
588 | (a) the band-aid fix is to link the _socket module statically\r | |
589 | rather than dynamically (which is the default).\r | |
590 | \r | |
591 | To do this, run "./configure --with-threads=no" including any\r | |
592 | other options you need (--prefix, etc.). Then in Modules/Setup\r | |
593 | uncomment the lines:\r | |
594 | \r | |
595 | #SSL=/usr/local/ssl\r | |
596 | #_socket socketmodule.c \\r | |
597 | # -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \\r | |
598 | # -L$(SSL)/lib -lssl -lcrypto\r | |
599 | \r | |
600 | and remove "local/" from the SSL variable. Finally, just run\r | |
601 | "make"!\r | |
602 | \r | |
603 | (b) The "proper" fix is to rebase the Cygwin DLLs to prevent\r | |
604 | base address conflicts. Details on how to do this can be\r | |
605 | found in the following mail:\r | |
606 | \r | |
607 | http://sources.redhat.com/ml/cygwin/2001-12/msg00894.html\r | |
608 | \r | |
609 | It is hoped that a version of this solution will be\r | |
610 | incorporated into the Cygwin distribution fairly soon.\r | |
611 | \r | |
612 | Two additional problems:\r | |
613 | \r | |
614 | (1) Threading support should still be disabled due to a known\r | |
615 | bug in Cygwin pthreads that causes test_threadedtempfile to\r | |
616 | hang.\r | |
617 | \r | |
618 | (2) The _curses module does not build. This is a known\r | |
619 | Cygwin ncurses problem that should be resolved the next time\r | |
620 | that this package is released.\r | |
621 | \r | |
622 | On older versions of Cygwin, test_poll may hang and test_strftime\r | |
623 | may fail.\r | |
624 | \r | |
625 | The situation on 9X/Me is not accurately known at present.\r | |
626 | Some time ago, there were reports that the following\r | |
627 | regression tests failed:\r | |
628 | \r | |
629 | test_pwd\r | |
630 | test_select (hang)\r | |
631 | test_socket\r | |
632 | \r | |
633 | Due to the test_select hang on 9X/Me, one should run the\r | |
634 | regression test using the following:\r | |
635 | \r | |
636 | make TESTOPTS='-l -x test_select' test\r | |
637 | \r | |
638 | News regarding these platforms with more recent Cygwin\r | |
639 | versions would be appreciated!\r | |
640 | \r | |
641 | Windows: When executing Python scripts on the command line using file type\r | |
642 | associations (i.e. starting "script.py" instead of "python script.py"),\r | |
643 | redirects may not work unless you set a specific registry key. See\r | |
644 | the Knowledge Base article <http://support.microsoft.com/kb/321788>.\r | |
645 | \r | |
646 | \r | |
647 | Configuring the bsddb and dbm modules\r | |
648 | -------------------------------------\r | |
649 | \r | |
650 | Beginning with Python version 2.3, the PyBsddb package\r | |
651 | <http://pybsddb.sf.net/> was adopted into Python as the bsddb package,\r | |
652 | exposing a set of package-level functions which provide\r | |
653 | backwards-compatible behavior. Only versions 3.3 through 4.4 of\r | |
654 | Sleepycat's libraries provide the necessary API, so older versions\r | |
655 | aren't supported through this interface. The old bsddb module has\r | |
656 | been retained as bsddb185, though it is not built by default. Users\r | |
657 | wishing to use it will have to tweak Modules/Setup to build it. The\r | |
658 | dbm module will still be built against the Sleepycat libraries if\r | |
659 | other preferred alternatives (ndbm, gdbm) are not found.\r | |
660 | \r | |
661 | Building the sqlite3 module\r | |
662 | ---------------------------\r | |
663 | \r | |
664 | To build the sqlite3 module, you'll need the sqlite3 or libsqlite3\r | |
665 | packages installed, including the header files. Many modern operating\r | |
666 | systems distribute the headers in a separate package to the library -\r | |
667 | often it will be the same name as the main package, but with a -dev or\r | |
668 | -devel suffix. \r | |
669 | \r | |
670 | The version of pysqlite2 that's including in Python needs sqlite3 3.0.8\r | |
671 | or later. setup.py attempts to check that it can find a correct version.\r | |
672 | \r | |
673 | Configuring threads\r | |
674 | -------------------\r | |
675 | \r | |
676 | As of Python 2.0, threads are enabled by default. If you wish to\r | |
677 | compile without threads, or if your thread support is broken, pass the\r | |
678 | --with-threads=no switch to configure. Unfortunately, on some\r | |
679 | platforms, additional compiler and/or linker options are required for\r | |
680 | threads to work properly. Below is a table of those options,\r | |
681 | collected by Bill Janssen. We would love to automate this process\r | |
682 | more, but the information below is not enough to write a patch for the\r | |
683 | configure.in file, so manual intervention is required. If you patch\r | |
684 | the configure.in file and are confident that the patch works, please\r | |
685 | send in the patch. (Don't bother patching the configure script itself\r | |
686 | -- it is regenerated each time the configure.in file changes.)\r | |
687 | \r | |
688 | Compiler switches for threads\r | |
689 | .............................\r | |
690 | \r | |
691 | The definition of _REENTRANT should be configured automatically, if\r | |
692 | that does not work on your system, or if _REENTRANT is defined\r | |
693 | incorrectly, please report that as a bug.\r | |
694 | \r | |
695 | OS/Compiler/threads Switches for use with threads\r | |
696 | (POSIX is draft 10, DCE is draft 4) compile & link\r | |
697 | \r | |
698 | SunOS 5.{1-5}/{gcc,SunPro cc}/solaris -mt\r | |
699 | SunOS 5.5/{gcc,SunPro cc}/POSIX (nothing)\r | |
700 | DEC OSF/1 3.x/cc/DCE -threads\r | |
701 | (butenhof@zko.dec.com)\r | |
702 | Digital UNIX 4.x/cc/DCE -threads\r | |
703 | (butenhof@zko.dec.com)\r | |
704 | Digital UNIX 4.x/cc/POSIX -pthread\r | |
705 | (butenhof@zko.dec.com)\r | |
706 | AIX 4.1.4/cc_r/d7 (nothing)\r | |
707 | (buhrt@iquest.net)\r | |
708 | AIX 4.1.4/cc_r4/DCE (nothing)\r | |
709 | (buhrt@iquest.net)\r | |
710 | IRIX 6.2/cc/POSIX (nothing)\r | |
711 | (robertl@cwi.nl)\r | |
712 | \r | |
713 | \r | |
714 | Linker (ld) libraries and flags for threads\r | |
715 | ...........................................\r | |
716 | \r | |
717 | OS/threads Libraries/switches for use with threads\r | |
718 | \r | |
719 | SunOS 5.{1-5}/solaris -lthread\r | |
720 | SunOS 5.5/POSIX -lpthread\r | |
721 | DEC OSF/1 3.x/DCE -lpthreads -lmach -lc_r -lc\r | |
722 | (butenhof@zko.dec.com)\r | |
723 | Digital UNIX 4.x/DCE -lpthreads -lpthread -lmach -lexc -lc\r | |
724 | (butenhof@zko.dec.com)\r | |
725 | Digital UNIX 4.x/POSIX -lpthread -lmach -lexc -lc\r | |
726 | (butenhof@zko.dec.com)\r | |
727 | AIX 4.1.4/{draft7,DCE} (nothing)\r | |
728 | (buhrt@iquest.net)\r | |
729 | IRIX 6.2/POSIX -lpthread\r | |
730 | (jph@emilia.engr.sgi.com)\r | |
731 | \r | |
732 | \r | |
733 | Building a shared libpython\r | |
734 | ---------------------------\r | |
735 | \r | |
736 | Starting with Python 2.3, the majority of the interpreter can be built\r | |
737 | into a shared library, which can then be used by the interpreter\r | |
738 | executable, and by applications embedding Python. To enable this feature,\r | |
739 | configure with --enable-shared.\r | |
740 | \r | |
741 | If you enable this feature, the same object files will be used to create\r | |
742 | a static library. In particular, the static library will contain object\r | |
743 | files using position-independent code (PIC) on platforms where PIC flags\r | |
744 | are needed for the shared library.\r | |
745 | \r | |
746 | \r | |
747 | Configuring additional built-in modules\r | |
748 | ---------------------------------------\r | |
749 | \r | |
750 | Starting with Python 2.1, the setup.py script at the top of the source\r | |
751 | distribution attempts to detect which modules can be built and\r | |
752 | automatically compiles them. Autodetection doesn't always work, so\r | |
753 | you can still customize the configuration by editing the Modules/Setup\r | |
754 | file; but this should be considered a last resort. The rest of this\r | |
755 | section only applies if you decide to edit the Modules/Setup file.\r | |
756 | You also need this to enable static linking of certain modules (which\r | |
757 | is needed to enable profiling on some systems).\r | |
758 | \r | |
759 | This file is initially copied from Setup.dist by the configure script;\r | |
760 | if it does not exist yet, create it by copying Modules/Setup.dist\r | |
761 | yourself (configure will never overwrite it). Never edit Setup.dist\r | |
762 | -- always edit Setup or Setup.local (see below). Read the comments in\r | |
763 | the file for information on what kind of edits are allowed. When you\r | |
764 | have edited Setup in the Modules directory, the interpreter will\r | |
765 | automatically be rebuilt the next time you run make (in the toplevel\r | |
766 | directory).\r | |
767 | \r | |
768 | Many useful modules can be built on any Unix system, but some optional\r | |
769 | modules can't be reliably autodetected. Often the quickest way to\r | |
770 | determine whether a particular module works or not is to see if it\r | |
771 | will build: enable it in Setup, then if you get compilation or link\r | |
772 | errors, disable it -- you're either missing support or need to adjust\r | |
773 | the compilation and linking parameters for that module.\r | |
774 | \r | |
775 | On SGI IRIX, there are modules that interface to many SGI specific\r | |
776 | system libraries, e.g. the GL library and the audio hardware. These\r | |
777 | modules will not be built by the setup.py script.\r | |
778 | \r | |
779 | In addition to the file Setup, you can also edit the file Setup.local.\r | |
780 | (the makesetup script processes both). You may find it more\r | |
781 | convenient to edit Setup.local and leave Setup alone. Then, when\r | |
782 | installing a new Python version, you can copy your old Setup.local\r | |
783 | file.\r | |
784 | \r | |
785 | \r | |
786 | Setting the optimization/debugging options\r | |
787 | ------------------------------------------\r | |
788 | \r | |
789 | If you want or need to change the optimization/debugging options for\r | |
790 | the C compiler, assign to the OPT variable on the toplevel make\r | |
791 | command; e.g. "make OPT=-g" will build a debugging version of Python\r | |
792 | on most platforms. The default is OPT=-O; a value for OPT in the\r | |
793 | environment when the configure script is run overrides this default\r | |
794 | (likewise for CC; and the initial value for LIBS is used as the base\r | |
795 | set of libraries to link with).\r | |
796 | \r | |
797 | When compiling with GCC, the default value of OPT will also include\r | |
798 | the -Wall and -Wstrict-prototypes options.\r | |
799 | \r | |
800 | Additional debugging code to help debug memory management problems can\r | |
801 | be enabled by using the --with-pydebug option to the configure script.\r | |
802 | \r | |
803 | For flags that change binary compatibility, use the EXTRA_CFLAGS\r | |
804 | variable.\r | |
805 | \r | |
806 | \r | |
807 | Profiling\r | |
808 | ---------\r | |
809 | \r | |
810 | If you want C profiling turned on, the easiest way is to run configure\r | |
811 | with the CC environment variable to the necessary compiler\r | |
812 | invocation. For example, on Linux, this works for profiling using\r | |
813 | gprof(1):\r | |
814 | \r | |
815 | CC="gcc -pg" ./configure\r | |
816 | \r | |
817 | Note that on Linux, gprof apparently does not work for shared\r | |
818 | libraries. The Makefile/Setup mechanism can be used to compile and\r | |
819 | link most extension modules statically.\r | |
820 | \r | |
821 | \r | |
822 | Coverage checking\r | |
823 | -----------------\r | |
824 | \r | |
825 | For C coverage checking using gcov, run "make coverage". This will\r | |
826 | build a Python binary with profiling activated, and a ".gcno" and\r | |
827 | ".gcda" file for every source file compiled with that option. With\r | |
828 | the built binary, now run the code whose coverage you want to check.\r | |
829 | Then, you can see coverage statistics for each individual source file\r | |
830 | by running gcov, e.g.\r | |
831 | \r | |
832 | gcov -o Modules zlibmodule\r | |
833 | \r | |
834 | This will create a "zlibmodule.c.gcov" file in the current directory\r | |
835 | containing coverage info for that source file.\r | |
836 | \r | |
837 | This works only for source files statically compiled into the\r | |
838 | executable; use the Makefile/Setup mechanism to compile and link\r | |
839 | extension modules you want to coverage-check statically.\r | |
840 | \r | |
841 | \r | |
842 | Testing\r | |
843 | -------\r | |
844 | \r | |
845 | To test the interpreter, type "make test" in the top-level directory.\r | |
846 | This runs the test set twice (once with no compiled files, once with\r | |
847 | the compiled files left by the previous test run). The test set\r | |
848 | produces some output. You can generally ignore the messages about\r | |
849 | skipped tests due to optional features which can't be imported.\r | |
850 | If a message is printed about a failed test or a traceback or core\r | |
851 | dump is produced, something is wrong. On some Linux systems (those\r | |
852 | that are not yet using glibc 6), test_strftime fails due to a\r | |
853 | non-standard implementation of strftime() in the C library. Please\r | |
854 | ignore this, or upgrade to glibc version 6.\r | |
855 | \r | |
856 | By default, tests are prevented from overusing resources like disk space and\r | |
857 | memory. To enable these tests, run "make testall".\r | |
858 | \r | |
859 | IMPORTANT: If the tests fail and you decide to mail a bug report,\r | |
860 | *don't* include the output of "make test". It is useless. Run the\r | |
861 | failing test manually, as follows:\r | |
862 | \r | |
863 | ./python Lib/test/regrtest.py -v test_whatever\r | |
864 | \r | |
865 | (substituting the top of the source tree for '.' if you built in a\r | |
866 | different directory). This runs the test in verbose mode.\r | |
867 | \r | |
868 | \r | |
869 | Installing\r | |
870 | ----------\r | |
871 | \r | |
872 | To install the Python binary, library modules, shared library modules\r | |
873 | (see below), include files, configuration files, and the manual page,\r | |
874 | just type\r | |
875 | \r | |
876 | make install\r | |
877 | \r | |
878 | This will install all platform-independent files in subdirectories of\r | |
879 | the directory given with the --prefix option to configure or to the\r | |
880 | `prefix' Make variable (default /usr/local). All binary and other\r | |
881 | platform-specific files will be installed in subdirectories if the\r | |
882 | directory given by --exec-prefix or the `exec_prefix' Make variable\r | |
883 | (defaults to the --prefix directory) is given.\r | |
884 | \r | |
885 | If DESTDIR is set, it will be taken as the root directory of the\r | |
886 | installation, and files will be installed into $(DESTDIR)$(prefix),\r | |
887 | $(DESTDIR)$(exec_prefix), etc.\r | |
888 | \r | |
889 | All subdirectories created will have Python's version number in their\r | |
890 | name, e.g. the library modules are installed in\r | |
891 | "/usr/local/lib/python<version>/" by default, where <version> is the\r | |
892 | <major>.<minor> release number (e.g. "2.1"). The Python binary is\r | |
893 | installed as "python<version>" and a hard link named "python" is\r | |
894 | created. The only file not installed with a version number in its\r | |
895 | name is the manual page, installed as "/usr/local/man/man1/python.1"\r | |
896 | by default.\r | |
897 | \r | |
898 | If you want to install multiple versions of Python see the section below\r | |
899 | entitled "Installing multiple versions".\r | |
900 | \r | |
901 | The only thing you may have to install manually is the Python mode for\r | |
902 | Emacs found in Misc/python-mode.el. (But then again, more recent\r | |
903 | versions of Emacs may already have it.) Follow the instructions that\r | |
904 | came with Emacs for installation of site-specific files.\r | |
905 | \r | |
906 | On Mac OS X, if you have configured Python with --enable-framework, you\r | |
907 | should use "make frameworkinstall" to do the installation. Note that this\r | |
908 | installs the Python executable in a place that is not normally on your\r | |
909 | PATH, you may want to set up a symlink in /usr/local/bin.\r | |
910 | \r | |
911 | \r | |
912 | Installing multiple versions\r | |
913 | ----------------------------\r | |
914 | \r | |
915 | On Unix and Mac systems if you intend to install multiple versions of Python\r | |
916 | using the same installation prefix (--prefix argument to the configure\r | |
917 | script) you must take care that your primary python executable is not\r | |
918 | overwritten by the installation of a different version. All files and\r | |
919 | directories installed using "make altinstall" contain the major and minor\r | |
920 | version and can thus live side-by-side. "make install" also creates\r | |
921 | ${prefix}/bin/python which refers to ${prefix}/bin/pythonX.Y. If you intend\r | |
922 | to install multiple versions using the same prefix you must decide which\r | |
923 | version (if any) is your "primary" version. Install that version using\r | |
924 | "make install". Install all other versions using "make altinstall".\r | |
925 | \r | |
926 | For example, if you want to install Python 2.5, 2.6 and 3.0 with 2.6 being\r | |
927 | the primary version, you would execute "make install" in your 2.6 build\r | |
928 | directory and "make altinstall" in the others.\r | |
929 | \r | |
930 | \r | |
931 | Configuration options and variables\r | |
932 | -----------------------------------\r | |
933 | \r | |
934 | Some special cases are handled by passing options to the configure\r | |
935 | script.\r | |
936 | \r | |
937 | WARNING: if you rerun the configure script with different options, you\r | |
938 | must run "make clean" before rebuilding. Exceptions to this rule:\r | |
939 | after changing --prefix or --exec-prefix, all you need to do is remove\r | |
940 | Modules/getpath.o.\r | |
941 | \r | |
942 | --with(out)-gcc: The configure script uses gcc (the GNU C compiler) if\r | |
943 | it finds it. If you don't want this, or if this compiler is\r | |
944 | installed but broken on your platform, pass the option\r | |
945 | --without-gcc. You can also pass "CC=cc" (or whatever the\r | |
946 | name of the proper C compiler is) in the environment, but the\r | |
947 | advantage of using --without-gcc is that this option is\r | |
948 | remembered by the config.status script for its --recheck\r | |
949 | option.\r | |
950 | \r | |
951 | --prefix, --exec-prefix: If you want to install the binaries and the\r | |
952 | Python library somewhere else than in /usr/local/{bin,lib},\r | |
953 | you can pass the option --prefix=DIRECTORY; the interpreter\r | |
954 | binary will be installed as DIRECTORY/bin/python and the\r | |
955 | library files as DIRECTORY/lib/python/*. If you pass\r | |
956 | --exec-prefix=DIRECTORY (as well) this overrides the\r | |
957 | installation prefix for architecture-dependent files (like the\r | |
958 | interpreter binary). Note that --prefix=DIRECTORY also\r | |
959 | affects the default module search path (sys.path), when\r | |
960 | Modules/config.c is compiled. Passing make the option\r | |
961 | prefix=DIRECTORY (and/or exec_prefix=DIRECTORY) overrides the\r | |
962 | prefix set at configuration time; this may be more convenient\r | |
963 | than re-running the configure script if you change your mind\r | |
964 | about the install prefix.\r | |
965 | \r | |
966 | --with-readline: This option is no longer supported. GNU\r | |
967 | readline is automatically enabled by setup.py when present.\r | |
968 | \r | |
969 | --with-threads: On most Unix systems, you can now use multiple\r | |
970 | threads, and support for this is enabled by default. To\r | |
971 | disable this, pass --with-threads=no. If the library required\r | |
972 | for threads lives in a peculiar place, you can use\r | |
973 | --with-thread=DIRECTORY. IMPORTANT: run "make clean" after\r | |
974 | changing (either enabling or disabling) this option, or you\r | |
975 | will get link errors! Note: for DEC Unix use\r | |
976 | --with-dec-threads instead.\r | |
977 | \r | |
978 | --with-sgi-dl: On SGI IRIX 4, dynamic loading of extension modules is\r | |
979 | supported by the "dl" library by Jack Jansen, which is\r | |
980 | ftp'able from ftp://ftp.cwi.nl/pub/dynload/dl-1.6.tar.Z.\r | |
981 | This is enabled (after you've ftp'ed and compiled the dl\r | |
982 | library) by passing --with-sgi-dl=DIRECTORY where DIRECTORY\r | |
983 | is the absolute pathname of the dl library. (Don't bother on\r | |
984 | IRIX 5, it already has dynamic linking using SunOS style\r | |
985 | shared libraries.) THIS OPTION IS UNSUPPORTED.\r | |
986 | \r | |
987 | --with-dl-dld: Dynamic loading of modules is rumored to be supported\r | |
988 | on some other systems: VAX (Ultrix), Sun3 (SunOS 3.4), Sequent\r | |
989 | Symmetry (Dynix), and Atari ST. This is done using a\r | |
990 | combination of the GNU dynamic loading package\r | |
991 | (ftp://ftp.cwi.nl/pub/dynload/dl-dld-1.1.tar.Z) and an\r | |
992 | emulation of the SGI dl library mentioned above (the emulation\r | |
993 | can be found at\r | |
994 | ftp://ftp.cwi.nl/pub/dynload/dld-3.2.3.tar.Z). To\r | |
995 | enable this, ftp and compile both libraries, then call\r | |
996 | configure, passing it the option\r | |
997 | --with-dl-dld=DL_DIRECTORY,DLD_DIRECTORY where DL_DIRECTORY is\r | |
998 | the absolute pathname of the dl emulation library and\r | |
999 | DLD_DIRECTORY is the absolute pathname of the GNU dld library.\r | |
1000 | (Don't bother on SunOS 4 or 5, they already have dynamic\r | |
1001 | linking using shared libraries.) THIS OPTION IS UNSUPPORTED.\r | |
1002 | \r | |
1003 | --with-libm, --with-libc: It is possible to specify alternative\r | |
1004 | versions for the Math library (default -lm) and the C library\r | |
1005 | (default the empty string) using the options\r | |
1006 | --with-libm=STRING and --with-libc=STRING, respectively. For\r | |
1007 | example, if your system requires that you pass -lc_s to the C\r | |
1008 | compiler to use the shared C library, you can pass\r | |
1009 | --with-libc=-lc_s. These libraries are passed after all other\r | |
1010 | libraries, the C library last.\r | |
1011 | \r | |
1012 | --with-libs='libs': Add 'libs' to the LIBS that the python interpreter\r | |
1013 | is linked against.\r | |
1014 | \r | |
1015 | --with-cxx-main=<compiler>: If you plan to use C++ extension modules,\r | |
1016 | then -- on some platforms -- you need to compile python's main()\r | |
1017 | function with the C++ compiler. With this option, make will use\r | |
1018 | <compiler> to compile main() *and* to link the python executable.\r | |
1019 | It is likely that the resulting executable depends on the C++\r | |
1020 | runtime library of <compiler>. (The default is --without-cxx-main.)\r | |
1021 | \r | |
1022 | There are platforms that do not require you to build Python\r | |
1023 | with a C++ compiler in order to use C++ extension modules.\r | |
1024 | E.g., x86 Linux with ELF shared binaries and GCC 3.x, 4.x is such\r | |
1025 | a platform. We recommend that you configure Python\r | |
1026 | --without-cxx-main on those platforms because a mismatch\r | |
1027 | between the C++ compiler version used to build Python and to\r | |
1028 | build a C++ extension module is likely to cause a crash at\r | |
1029 | runtime.\r | |
1030 | \r | |
1031 | The Python installation also stores the variable CXX that\r | |
1032 | determines, e.g., the C++ compiler distutils calls by default\r | |
1033 | to build C++ extensions. If you set CXX on the configure command\r | |
1034 | line to any string of non-zero length, then configure won't\r | |
1035 | change CXX. If you do not preset CXX but pass\r | |
1036 | --with-cxx-main=<compiler>, then configure sets CXX=<compiler>.\r | |
1037 | In all other cases, configure looks for a C++ compiler by\r | |
1038 | some common names (c++, g++, gcc, CC, cxx, cc++, cl) and sets\r | |
1039 | CXX to the first compiler it finds. If it does not find any\r | |
1040 | C++ compiler, then it sets CXX="".\r | |
1041 | \r | |
1042 | Similarly, if you want to change the command used to link the\r | |
1043 | python executable, then set LINKCC on the configure command line.\r | |
1044 | \r | |
1045 | \r | |
1046 | --with-pydebug: Enable additional debugging code to help track down\r | |
1047 | memory management problems. This allows printing a list of all\r | |
1048 | live objects when the interpreter terminates.\r | |
1049 | \r | |
1050 | --with(out)-universal-newlines: enable reading of text files with\r | |
1051 | foreign newline convention (default: enabled). In other words,\r | |
1052 | any of \r, \n or \r\n is acceptable as end-of-line character.\r | |
1053 | If enabled import and execfile will automatically accept any newline\r | |
1054 | in files. Python code can open a file with open(file, 'U') to\r | |
1055 | read it in universal newline mode. THIS OPTION IS UNSUPPORTED.\r | |
1056 | \r | |
1057 | --with-tsc: Profile using the Pentium timestamping counter (TSC).\r | |
1058 | \r | |
1059 | --with-system-ffi: Build the _ctypes extension module using an ffi\r | |
1060 | library installed on the system.\r | |
1061 | \r | |
1062 | --with-dbmliborder=db1:db2:...: Specify the order that backends for the\r | |
1063 | dbm extension are checked. Valid value is a colon separated string\r | |
1064 | with the backend names `ndbm', `gdbm' and `bdb'.\r | |
1065 | \r | |
1066 | Building for multiple architectures (using the VPATH feature)\r | |
1067 | -------------------------------------------------------------\r | |
1068 | \r | |
1069 | If your file system is shared between multiple architectures, it\r | |
1070 | usually is not necessary to make copies of the sources for each\r | |
1071 | architecture you want to support. If the make program supports the\r | |
1072 | VPATH feature, you can create an empty build directory for each\r | |
1073 | architecture, and in each directory run the configure script (on the\r | |
1074 | appropriate machine with the appropriate options). This creates the\r | |
1075 | necessary subdirectories and the Makefiles therein. The Makefiles\r | |
1076 | contain a line VPATH=... which points to a directory containing the\r | |
1077 | actual sources. (On SGI systems, use "smake -J1" instead of "make" if\r | |
1078 | you use VPATH -- don't try gnumake.)\r | |
1079 | \r | |
1080 | For example, the following is all you need to build a minimal Python\r | |
1081 | in /usr/tmp/python (assuming ~guido/src/python is the toplevel\r | |
1082 | directory and you want to build in /usr/tmp/python):\r | |
1083 | \r | |
1084 | $ mkdir /usr/tmp/python\r | |
1085 | $ cd /usr/tmp/python\r | |
1086 | $ ~guido/src/python/configure\r | |
1087 | [...]\r | |
1088 | $ make\r | |
1089 | [...]\r | |
1090 | $\r | |
1091 | \r | |
1092 | Note that configure copies the original Setup file to the build\r | |
1093 | directory if it finds no Setup file there. This means that you can\r | |
1094 | edit the Setup file for each architecture independently. For this\r | |
1095 | reason, subsequent changes to the original Setup file are not tracked\r | |
1096 | automatically, as they might overwrite local changes. To force a copy\r | |
1097 | of a changed original Setup file, delete the target Setup file. (The\r | |
1098 | makesetup script supports multiple input files, so if you want to be\r | |
1099 | fancy you can change the rules to create an empty Setup.local if it\r | |
1100 | doesn't exist and run it with arguments $(srcdir)/Setup Setup.local;\r | |
1101 | however this assumes that you only need to add modules.)\r | |
1102 | \r | |
1103 | Also note that you can't use a workspace for VPATH and non VPATH builds. The\r | |
1104 | object files left behind by one version confuses the other.\r | |
1105 | \r | |
1106 | \r | |
1107 | Building on non-UNIX systems\r | |
1108 | ----------------------------\r | |
1109 | \r | |
1110 | For Windows (2000/NT/ME/98/95), assuming you have MS VC++ 7.1, the\r | |
1111 | project files are in PCbuild, the workspace is pcbuild.dsw. See\r | |
1112 | PCbuild\readme.txt for detailed instructions.\r | |
1113 | \r | |
1114 | For other non-Unix Windows compilers, in particular MS VC++ 6.0 and\r | |
1115 | for OS/2, enter the directory "PC" and read the file "readme.txt".\r | |
1116 | \r | |
1117 | For the Mac, a separate source distribution will be made available,\r | |
1118 | for use with the CodeWarrior compiler. If you are interested in Mac\r | |
1119 | development, join the PythonMac Special Interest Group\r | |
1120 | (http://www.python.org/sigs/pythonmac-sig/, or send email to\r | |
1121 | pythonmac-sig-request@python.org).\r | |
1122 | \r | |
1123 | Of course, there are also binary distributions available for these\r | |
1124 | platforms -- see http://www.python.org/.\r | |
1125 | \r | |
1126 | To port Python to a new non-UNIX system, you will have to fake the\r | |
1127 | effect of running the configure script manually (for Mac and PC, this\r | |
1128 | has already been done for you). A good start is to copy the file\r | |
1129 | pyconfig.h.in to pyconfig.h and edit the latter to reflect the actual\r | |
1130 | configuration of your system. Most symbols must simply be defined as\r | |
1131 | 1 only if the corresponding feature is present and can be left alone\r | |
1132 | otherwise; however the *_t type symbols must be defined as some\r | |
1133 | variant of int if they need to be defined at all.\r | |
1134 | \r | |
1135 | For all platforms, it's important that the build arrange to define the\r | |
1136 | preprocessor symbol NDEBUG on the compiler command line in a release\r | |
1137 | build of Python (else assert() calls remain in the code, hurting\r | |
1138 | release-build performance). The Unix, Windows and Mac builds already\r | |
1139 | do this.\r | |
1140 | \r | |
1141 | \r | |
1142 | Miscellaneous issues\r | |
1143 | ====================\r | |
1144 | \r | |
1145 | Emacs mode\r | |
1146 | ----------\r | |
1147 | \r | |
1148 | There's an excellent Emacs editing mode for Python code; see the file\r | |
1149 | Misc/python-mode.el. Originally written by the famous Tim Peters, it is now\r | |
1150 | maintained by the equally famous Barry Warsaw. The latest version, along with\r | |
1151 | various other contributed Python-related Emacs goodies, is online at\r | |
1152 | http://launchpad.net/python-mode/.\r | |
1153 | \r | |
1154 | \r | |
1155 | Tkinter\r | |
1156 | -------\r | |
1157 | \r | |
1158 | The setup.py script automatically configures this when it detects a\r | |
1159 | usable Tcl/Tk installation. This requires Tcl/Tk version 8.0 or\r | |
1160 | higher.\r | |
1161 | \r | |
1162 | For more Tkinter information, see the Tkinter Resource page:\r | |
1163 | http://www.python.org/topics/tkinter/\r | |
1164 | \r | |
1165 | There are demos in the Demo/tkinter directory.\r | |
1166 | \r | |
1167 | Note that there's a Python module called "Tkinter" (capital T) which\r | |
1168 | lives in Lib/lib-tk/Tkinter.py, and a C module called "_tkinter"\r | |
1169 | (lower case t and leading underscore) which lives in\r | |
1170 | Modules/_tkinter.c. Demos and normal Tk applications import only the\r | |
1171 | Python Tkinter module -- only the latter imports the C _tkinter\r | |
1172 | module. In order to find the C _tkinter module, it must be compiled\r | |
1173 | and linked into the Python interpreter -- the setup.py script does\r | |
1174 | this. In order to find the Python Tkinter module, sys.path must be\r | |
1175 | set correctly -- normal installation takes care of this.\r | |
1176 | \r | |
1177 | \r | |
1178 | Distribution structure\r | |
1179 | ----------------------\r | |
1180 | \r | |
1181 | Most subdirectories have their own README files. Most files have\r | |
1182 | comments.\r | |
1183 | \r | |
1184 | Demo/ Demonstration scripts, modules and programs\r | |
1185 | Doc/ Documentation sources (reStructuredText)\r | |
1186 | Grammar/ Input for the parser generator\r | |
1187 | Include/ Public header files\r | |
1188 | LICENSE Licensing information\r | |
1189 | Lib/ Python library modules\r | |
1190 | Mac/ Macintosh specific resources\r | |
1191 | Makefile.pre.in Source from which config.status creates the Makefile.pre\r | |
1192 | Misc/ Miscellaneous useful files\r | |
1193 | Modules/ Implementation of most built-in modules\r | |
1194 | Objects/ Implementation of most built-in object types\r | |
1195 | PC/ Files specific to PC ports (DOS, Windows, OS/2)\r | |
1196 | PCbuild/ Build directory for Microsoft Visual C++\r | |
1197 | Parser/ The parser and tokenizer and their input handling\r | |
1198 | Python/ The byte-compiler and interpreter\r | |
1199 | README The file you're reading now\r | |
1200 | RISCOS/ Files specific to RISC OS port\r | |
1201 | Tools/ Some useful programs written in Python\r | |
1202 | pyconfig.h.in Source from which pyconfig.h is created (GNU autoheader output)\r | |
1203 | configure Configuration shell script (GNU autoconf output)\r | |
1204 | configure.in Configuration specification (input for GNU autoconf)\r | |
1205 | install-sh Shell script used to install files\r | |
1206 | setup.py Python script used to build extension modules\r | |
1207 | \r | |
1208 | The following files will (may) be created in the toplevel directory by\r | |
1209 | the configuration and build processes:\r | |
1210 | \r | |
1211 | Makefile Build rules\r | |
1212 | Makefile.pre Build rules before running Modules/makesetup\r | |
1213 | buildno Keeps track of the build number\r | |
1214 | config.cache Cache of configuration variables\r | |
1215 | pyconfig.h Configuration header\r | |
1216 | config.log Log from last configure run\r | |
1217 | config.status Status from last run of the configure script\r | |
1218 | getbuildinfo.o Object file from Modules/getbuildinfo.c\r | |
1219 | libpython<version>.a The library archive\r | |
1220 | python The executable interpreter\r | |
1221 | reflog.txt Output from running the regression suite with the -R flag \r | |
1222 | tags, TAGS Tags files for vi and Emacs\r | |
1223 | \r | |
1224 | \r | |
1225 | That's all, folks!\r | |
1226 | ------------------\r | |
1227 | \r | |
1228 | \r | |
1229 | --Guido van Rossum (home page: http://www.python.org/~guido/)\r |