diff options
author | Antoine Pitrou <solipsis@pitrou.net> | 2011-11-30 20:19:21 (GMT) |
---|---|---|
committer | Antoine Pitrou <solipsis@pitrou.net> | 2011-11-30 20:19:21 (GMT) |
commit | 71bca3495d975baec43215e9cfcc3d0142194ccb (patch) | |
tree | 018288606bd19777e2b61cba8c1d0053bfbab6f6 /Doc/extending | |
parent | a74f8ef419d2c7c5f398a80165f8d8fd5e4d7b8e (diff) | |
download | cpython-71bca3495d975baec43215e9cfcc3d0142194ccb.zip cpython-71bca3495d975baec43215e9cfcc3d0142194ccb.tar.gz cpython-71bca3495d975baec43215e9cfcc3d0142194ccb.tar.bz2 |
Issue #1040439: better document how to compile and link an embedded Python interpreter.
Still lacks docs for Windows (anyone?).
Diffstat (limited to 'Doc/extending')
-rw-r--r-- | Doc/extending/embedding.rst | 78 |
1 files changed, 47 insertions, 31 deletions
diff --git a/Doc/extending/embedding.rst b/Doc/extending/embedding.rst index e261048..ec93a16 100644 --- a/Doc/extending/embedding.rst +++ b/Doc/extending/embedding.rst @@ -133,8 +133,9 @@ The code to run a function defined in a Python script is: This code loads a Python script using ``argv[1]``, and calls the function named in ``argv[2]``. Its integer arguments are the other values of the ``argv`` -array. If you compile and link this program (let's call the finished executable -:program:`call`), and use it to execute a Python script, such as:: +array. If you :ref:`compile and link <compiling>` this program (let's call +the finished executable :program:`call`), and use it to execute a Python +script, such as:: def multiply(a,b): print("Will compute", a, "times", b) @@ -257,37 +258,52 @@ write the main program in C++, and use the C++ compiler to compile and link your program. There is no need to recompile Python itself using C++. -.. _link-reqs: +.. _compiling: -Linking Requirements -==================== - -While the :program:`configure` script shipped with the Python sources will -correctly build Python to export the symbols needed by dynamically linked -extensions, this is not automatically inherited by applications which embed the -Python library statically, at least on Unix. This is an issue when the -application is linked to the static runtime library (:file:`libpython.a`) and -needs to load dynamic extensions (implemented as :file:`.so` files). - -The problem is that some entry points are defined by the Python runtime solely -for extension modules to use. If the embedding application does not use any of -these entry points, some linkers will not include those entries in the symbol -table of the finished executable. Some additional options are needed to inform -the linker not to remove these symbols. - -Determining the right options to use for any given platform can be quite -difficult, but fortunately the Python configuration already has those values. -To retrieve them from an installed Python interpreter, start an interactive -interpreter and have a short session like this:: +Compiling and Linking under Unix-like systems +============================================= - >>> import distutils.sysconfig - >>> distutils.sysconfig.get_config_var('LINKFORSHARED') +It is not necessarily trivial to find the right flags to pass to your +compiler (and linker) in order to embed the Python interpreter into your +application, particularly because Python needs to load library modules +implemented as C dynamic extensions (:file:`.so` files) linked against +it. + +To find out the required compiler and linker flags, you can execute the +:file:`python{X.Y}-config` script which is generated as part of the +installation process (a generic :file:`python3-config` script is also +available). This script has several options, of which the following will +be directly useful to you: + +* ``pythonX.Y-config --cflags`` will give you the recommended flags when + compiling:: + + $ /opt/bin/python3.2-config --cflags + -I/opt/include/python3.2m -I/opt/include/python3.2m -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes + +* ``pythonX.Y-config --ldflags`` will give you the recommended flags when + linking:: + + $ /opt/bin/python3.2-config --ldflags + -I/opt/lib/python3.2/config-3.2m -lpthread -ldl -lutil -lm -lpython3.2m -Xlinker -export-dynamic + +.. note:: + To avoid confusion between several Python installations (and especially + between the system Python and your own compiled Python), it is recommended + that you use the absolute path to :file:`python{X.Y}-config`, as in the above + example. + +If this procedure doesn't work for you (it is not guaranteed to work for +all Unix-like platforms; however, we welcome bug reports at +http://bugs.python.org), you will have to read your system's documentation +about dynamic linking and/or examine Python's Makefile and compilation +options. In this case, the :mod:`sysconfig` module is a useful tool to +programmatically extract the configuration values that you will want to +combine together:: + + >>> import sysconfig + >>> sysconfig.get_config_var('LINKFORSHARED') '-Xlinker -export-dynamic' -.. index:: module: distutils.sysconfig - -The contents of the string presented will be the options that should be used. -If the string is empty, there's no need to add any additional options. The -:const:`LINKFORSHARED` definition corresponds to the variable of the same name -in Python's top-level :file:`Makefile`. +.. XXX similar documentation for Windows missing |