|
| 1 | +======================== |
| 2 | +Python Standalone Builds |
| 3 | +======================== |
| 4 | + |
| 5 | +This project contains code for building Python distributions that are |
| 6 | +self-contained and highly portable (the binaries can be executed |
| 7 | +on most target machines). |
| 8 | + |
| 9 | +The intended audience of this project are people wanting to produce |
| 10 | +applications that embed Python in a larger executable. The artifacts |
| 11 | +that this project produces make it easier to build highly-portable |
| 12 | +applications containing Python. |
| 13 | + |
| 14 | +Most consumers of this project can bypass the building of artifacts |
| 15 | +and consume the pre-built binaries produced from it. |
| 16 | + |
| 17 | +Project Status |
| 18 | +============== |
| 19 | + |
| 20 | +The project can be considered alpha quality. It is still in a heavy state |
| 21 | +of flux. |
| 22 | + |
| 23 | +Currently, it produces a nearly full-featured CPython distribution for |
| 24 | +Linux that is fully statically linked with the exception of some very |
| 25 | +common system libraries. |
| 26 | + |
| 27 | +Planned features include: |
| 28 | + |
| 29 | +* Support for Windows |
| 30 | +* Support for macOS |
| 31 | +* Static/dynamic linking toggles for dependencies |
| 32 | + |
| 33 | +Instructions |
| 34 | +============ |
| 35 | + |
| 36 | +To build a Python distribution for Linux x64:: |
| 37 | + |
| 38 | + $ ./build-linux.py |
| 39 | + |
| 40 | +Requirements |
| 41 | +============ |
| 42 | + |
| 43 | +Linux |
| 44 | +----- |
| 45 | + |
| 46 | +The host system must be 64-bit. A Python 3.5+ interpreter must be |
| 47 | +available. The execution environment must have access to a Docker |
| 48 | +daemon (all build operations are performed in Docker containers for |
| 49 | +isolation from the host system). |
| 50 | + |
| 51 | +How It Works |
| 52 | +============ |
| 53 | + |
| 54 | +The first thing the ``build-*`` scripts do is bootstrap an environment |
| 55 | +for building Python. On Linux, a base Docker image based on a deterministic |
| 56 | +snapshot of Debian Wheezy is created. A modern binutils and GCC are built |
| 57 | +in this environment. That modern GCC is then used to build a modern Clang. |
| 58 | +Clang is then used to build all of Python's dependencies (openssl, ncurses, |
| 59 | +readline, sqlite, etc). Finally, Python itself is built. |
| 60 | + |
| 61 | +Python is built in such a way that extensions are statically linked |
| 62 | +against their dependencies. e.g. instead of the ``sqlite3`` Python |
| 63 | +extension having a run-time dependency against ``libsqlite3.so``, the |
| 64 | +SQLite symbols are statically inlined into the Python extension object |
| 65 | +file. |
| 66 | + |
| 67 | +From the built Python, we produce an archive containing the raw Python |
| 68 | +distribution (as if you had run ``make install``) as well as other files |
| 69 | +useful for downstream consumers. |
| 70 | + |
| 71 | +Setup.local Hackery |
| 72 | +------------------- |
| 73 | + |
| 74 | +Python's build system reads the ``Modules/Setup`` and ``Modules/Setup.local`` |
| 75 | +files to influence how C extensions are built. By default, many extensions |
| 76 | +have no entry in these files and the ``setup.py`` script performs work |
| 77 | +to compile these extensions. (``setup.py`` looks for headers, libraries, |
| 78 | +etc, and sets up the proper compiler flags.) |
| 79 | + |
| 80 | +``setup.py`` doesn't provide a lot of flexibility and relies on a lot |
| 81 | +of default behavior in ``distutils`` as well as other inline code in |
| 82 | +``setup.py``. This default behavior is often undesirable for our |
| 83 | +desired outcome of producing a standalone Python distribution. |
| 84 | + |
| 85 | +Since the build environment is mostly deterministic and since we have |
| 86 | +special requirements, we generate a custom ``Setup.local`` file that |
| 87 | +builds C extensions in a specific manner. The undesirable behavior of |
| 88 | +``setup.py`` is bypassed and the Python C extensions are compiled just |
| 89 | +the way we want. |
| 90 | + |
| 91 | +Linux Runtime Requirements |
| 92 | +========================== |
| 93 | + |
| 94 | +The produced Linux binaries have minimal references to shared |
| 95 | +libraries and thus can be executed on most Linux systems. |
| 96 | + |
| 97 | +The following shared libraries are referenced: |
| 98 | + |
| 99 | +* linux-vdso.so.1 |
| 100 | +* libpthread.so.0 |
| 101 | +* libdl.so.2 (required by ctypes extension) |
| 102 | +* libutil.so.1 |
| 103 | +* librt.so.1 |
| 104 | +* libnsl.so.1 (required by nis extension) |
| 105 | +* libcrypt.so.1 (required by crypt extension) |
| 106 | +* libm.so.6 |
| 107 | +* libc.so.6 |
| 108 | +* ld-linux-x86-64.so.2 |
| 109 | + |
| 110 | +Licensing |
| 111 | +========= |
| 112 | + |
| 113 | +Python and its various dependencies are governed by varied software use |
| 114 | +licenses. This impacts the rights and requirements of downstream consumers. |
| 115 | + |
| 116 | +The ``python-licenses.rst`` file contained in this repository and produced |
| 117 | +artifacts summarizes the licenses of various components. |
| 118 | + |
| 119 | +Most licenses are fairly permissive. Notable exceptions to this are GDBM and |
| 120 | +readline, which are both licensed under GPL Version 3. |
| 121 | + |
| 122 | +**It is important to understand the licensing requirements when integrating |
| 123 | +the output of this project into derived works.** |
0 commit comments