diff options
| author | gatecat <gatecat@ds0.me> | 2022-09-14 09:28:47 +0200 | 
|---|---|---|
| committer | gatecat <gatecat@ds0.me> | 2022-09-14 09:28:47 +0200 | 
| commit | a72f898ff4c4237424c468044a6db9d6953b541e (patch) | |
| tree | 1c4a543f661dd1b281aecf4660388491702fa8d8 /3rdparty/pybind11/docs/faq.rst | |
| parent | f1349e114f3a16ccd002e8513339e18f5be4d31b (diff) | |
| download | nextpnr-a72f898ff4c4237424c468044a6db9d6953b541e.tar.gz nextpnr-a72f898ff4c4237424c468044a6db9d6953b541e.tar.bz2 nextpnr-a72f898ff4c4237424c468044a6db9d6953b541e.zip | |
3rdparty: Bump vendored pybind11 version for py3.11 support
Signed-off-by: gatecat <gatecat@ds0.me>
Diffstat (limited to '3rdparty/pybind11/docs/faq.rst')
| -rw-r--r-- | 3rdparty/pybind11/docs/faq.rst | 52 | 
1 files changed, 8 insertions, 44 deletions
| diff --git a/3rdparty/pybind11/docs/faq.rst b/3rdparty/pybind11/docs/faq.rst index 8bf05a40..28498e7d 100644 --- a/3rdparty/pybind11/docs/faq.rst +++ b/3rdparty/pybind11/docs/faq.rst @@ -5,12 +5,10 @@ Frequently asked questions  ===========================================================  1. Make sure that the name specified in PYBIND11_MODULE is identical to the -filename of the extension library (without suffixes such as .so) +filename of the extension library (without suffixes such as ``.so``).  2. If the above did not fix the issue, you are likely using an incompatible -version of Python (for instance, the extension library was compiled against -Python 2, while the interpreter is running on top of some version of Python -3, or vice versa). +version of Python that does not match what you compiled with.  "Symbol not found: ``__Py_ZeroStruct`` / ``_PyInstanceMethod_Type``"  ======================================================================== @@ -54,7 +52,7 @@ provided by the caller -- in fact, it does nothing at all.  .. code-block:: python      def increment(i): -        i += 1 # nope.. +        i += 1  # nope..  pybind11 is also affected by such language-level conventions, which means that  binding ``increment`` or ``increment_ptr`` will also create Python functions @@ -147,7 +145,7 @@ using C++14 template metaprogramming.  .. _`faq:hidden_visibility`: -"‘SomeClass’ declared with greater visibility than the type of its field ‘SomeClass::member’ [-Wattributes]" +"'SomeClass' declared with greater visibility than the type of its field 'SomeClass::member' [-Wattributes]"  ============================================================================================================  This error typically indicates that you are compiling without the required @@ -169,8 +167,8 @@ can be changed, but even if it isn't it is not always enough to guarantee  complete independence of the symbols involved when not using  ``-fvisibility=hidden``. -Additionally, ``-fvisiblity=hidden`` can deliver considerably binary size -savings.  (See the following section for more details). +Additionally, ``-fvisibility=hidden`` can deliver considerably binary size +savings. (See the following section for more details.)  .. _`faq:symhidden`: @@ -180,7 +178,7 @@ How can I create smaller binaries?  To do its job, pybind11 extensively relies on a programming technique known as  *template metaprogramming*, which is a way of performing computation at compile -time using type information. Template metaprogamming usually instantiates code +time using type information. Template metaprogramming usually instantiates code  involving significant numbers of deeply nested types that are either completely  removed or reduced to just a few instructions during the compiler's optimization  phase. However, due to the nested nature of these types, the resulting symbol @@ -222,20 +220,6 @@ In addition to decreasing binary size, ``-fvisibility=hidden`` also avoids  potential serious issues when loading multiple modules and is required for  proper pybind operation.  See the previous FAQ entry for more details. -Working with ancient Visual Studio 2008 builds on Windows -========================================================= - -The official Windows distributions of Python are compiled using truly -ancient versions of Visual Studio that lack good C++11 support. Some users -implicitly assume that it would be impossible to load a plugin built with -Visual Studio 2015 into a Python distribution that was compiled using Visual -Studio 2008. However, no such issue exists: it's perfectly legitimate to -interface DLLs that are built with different compilers and/or C libraries. -Common gotchas to watch out for involve not ``free()``-ing memory region -that that were ``malloc()``-ed in another shared library, using data -structures with incompatible ABIs, and so on. pybind11 is very careful not -to make these types of mistakes. -  How can I properly handle Ctrl-C in long-running functions?  =========================================================== @@ -289,27 +273,7 @@ Conflicts can arise, however, when using pybind11 in a project that *also* uses  the CMake Python detection in a system with several Python versions installed.  This difference may cause inconsistencies and errors if *both* mechanisms are -used in the same project. Consider the following CMake code executed in a -system with Python 2.7 and 3.x installed: - -.. code-block:: cmake - -    find_package(PythonInterp) -    find_package(PythonLibs) -    find_package(pybind11) - -It will detect Python 2.7 and pybind11 will pick it as well. - -In contrast this code: - -.. code-block:: cmake - -    find_package(pybind11) -    find_package(PythonInterp) -    find_package(PythonLibs) - -will detect Python 3.x for pybind11 and may crash on -``find_package(PythonLibs)`` afterwards. +used in the same project.  There are three possible solutions: | 
