[BUG]: undefined symbol: _ZNSt15__exception_ptr13exception_ptr10_M_releaseEv

[OlivierBinette]

Required prerequisites

• Make sure you've read the documentation. Your issue may be addressed there.
• Search the issue tracker and Discussions to verify that this hasn't already been reported. +1 or comment there if it has.
• Consider asking first in the Gitter chat room or in a Discussion.

Problem description

I've started getting a new error across all of my pybind11 projects when importing packages: "undefined symbol: _ZNSt15__exception_ptr13exception_ptr10_M_releaseEv" See reproducible example code for more information on the error.

Nothing major has changed in my configuration, so I'm not sure where the error is coming from.

System info:

> conda info
     active environment : base
    active env location : /home/olivier/anaconda3
            shell level : 1
       user config file : /home/olivier/.condarc
 populated config files : /home/olivier/.condarc
          conda version : 4.11.0
    conda-build version : 3.21.5
         python version : 3.9.7.final.0
       virtual packages : __linux=5.15.8=0
                          __glibc=2.34=0
                          __unix=0=0
                          __archspec=1=x86_64
       base environment : /home/olivier/anaconda3  (writable)
      conda av data dir : /home/olivier/anaconda3/etc/conda
  conda av metadata url : None
           channel URLs : https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /home/olivier/anaconda3/pkgs
                          /home/olivier/.conda/pkgs
       envs directories : /home/olivier/anaconda3/envs
                          /home/olivier/.conda/envs
               platform : linux-64
             user-agent : conda/4.11.0 requests/2.26.0 CPython/3.9.7 Linux/5.15.8-76051508-generic pop/21.10 glibc/2.34
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

Reproducible example code

> conda create -n python_example python=3.7.9 -y
> conda activate python_example
> git clone [email protected]:pybind/python_example.git
> pip install -e python_example/
> python
>>> import python_example
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /home/olivier/Desktop/Research/python_example/python_example.cpython-37m-x86_64-linux-gnu.so: undefined symbol: _ZNSt15__exception_ptr13exception_ptr10_M_releaseEv

[OlivierBinette]

I only get this error on my current laptop, which was recently upgraded from Pop!_OS 21.04 to Pop!_OS 21.10. I don't have any issue on my other linux machine. Pop!_OS 21.10 uses gcc 11, whereas Pop!_OS 21.04 uses gcc 10 by default, if I'm not mistaken.

[OlivierBinette]

Works when setting CC=gcc-9 and CXX=g++-9 now. I think there's more to look into.

[eirrgang]

With conda, in particular, it is easy to get mismatched toolchains or dependencies. Is the default pip provided by that py 3.7.9 conda environment? You could try using python -m pip instead to get the right version of pip.

Hint: use c++filt to decode the munged symbol name so that you can better guess what the compiler found and why the runtime linker can't find it.

[romankempt]

I have the same issue (see here https://stackoverflow.com/questions/70711640/c-program-compiles-and-links-but-then-raises-undefined-symbol-error). I can't reproduce it on my own machine, but it happens for colleagues every time. Gives me quite a headache by now

[OlivierBinette]

@eirrgang I tried using python -m pip instead and get the same error. Running c++filt yields:

std::__exception_ptr::exception_ptr::_M_release()

Update: I tried using venv instead of conda and didn't run into any issue with the installation.

[eirrgang]

I tried using venv instead of conda and didn't run into any issue with the installation

Exactly.

This is a symbol from the C++ standard library. Conda packages are often built with a different standard library implementation than the system default, so it is easy to end up with ABI incompatibilities between packages built with conda-build (or distributed as binary packages) and packages built locally with default compiler options. It used to frustrate me all the time, but I think modern CMake has been protecting me lately.

The short answer is that this is a toolchain compatibility issue with a toolchain solution: if specifying a particular compiler version is good enough to resolve it, you're lucky.

It seems like https://pybind11.readthedocs.io/en/stable/compiling.html or https://github.com/pybind/python_example could use some additional notes or checks.

A more descriptive title for this issue might be "pip install for python_example does not use consistent standard library in conda environments". I suspect the solution is not necessarily to improve the setuptools boilerplate, but to direct users to try the conda build or consult https://pybind11.readthedocs.io/en/stable/compiling.html for more guidance on build systems.

Maybe the https://github.com/pybind/python_example instructions could just point out that there is a Conda recipe. It is tested at https://github.com/pybind/python_example/blob/master/.github/workflows/conda.yml but not documented in the README. @OlivierBinette maybe you could follow the example of the CI test to use conda instead of pip when in a conda environment. If that works, would a small update to https://github.com/pybind/python_example/blob/master/README.md be a suitable resolution to this issue?

[eirrgang]

The issue described by @romankempt is actually quite distinct from this one. In both cases, the source code (or an included header) references a symbol at compile time that cannot be found at run time, but the reasons and solutions are different.

[clonker]

Hi @eirrgang, I would like to protect users from these issues. How does modern CMake protect from mismatched compiler/toolchain/dependencies? Does it automatically detect these issues and raise an appropriate error?
I am asking because I have been contemplating whether to move our (deeptime, linked issue above) build system to CMake entirely, this would be a good argument to invest the effort. 🙂

[eirrgang]

Hi @eirrgang, I would like to protect users from these issues. How does modern CMake protect from mismatched compiler/toolchain/dependencies? Does it automatically detect these issues and raise an appropriate error?

The short answer: properly support and use target_link_libraries().

CMake can do a lot of checking, but both the dependency packager and consumer need to use appropriate modern CMake patterns to allow CMake to do its what it can. Additionally, some pretty fundamental decisions are subjective (e.g. whether/how to set RPATH), so there isn't a single answer.

If you make yourself aware of concepts like compatible interface properties and transitive usage requirements, you'll be off to a good start. Thoughtful use of CXX_STANDARD, or deferring to the dependency's assertion of CXX_STANDARD_REQUIRED can be important.

Be sure to express important details in terms of compile features, target_compile_definitions, target_compile_options, etc, instead of bare flags.

If all else fails, the dependency can provide a hints file from which the consumer can initialize its CMake cache (using the -C command line option).

See also: discussion, warnings, and linked FAQs at https://pybind11.readthedocs.io/en/stable/compiling.html#advanced-interface-library-targets

[eirrgang]

I am asking because I have been contemplating whether to move our (deeptime, linked issue above) build system to CMake entirely, this would be a good argument to invest the effort.

Specifically with respect to pybind help and packaging/distributing Python projects with dependencies, there isn't yet a great and standardized way to tell the Python package tool to tell CMake everything it needs. The scikit-build project tries to help with that. I find https://github.com/pybind/cmake_example/blob/master/setup.py easier to use and maintain, and it is fairly straightforward to modify the example so that regular users don't have to specify a CMAKE_ARGS environment variable, if the dependency has some other way of hinting consumers about its dependencies/requirements.

The author @henryiii is actively working on further improvements by unifying the two efforts, as I understand it.

[clonker]

Wow, thank you for your thorough explanations! I did take a look at scikit-build yesterday and it seems like it fits our needs very well. I first tried adapting the CMake example you linked but it needs a bit of work if there are multiple c++ module targets (as it is right now, it would compile all targets for each individual CMakeExtension instance so it would require some more work to get the desired behavior).

In any case, skbuild was more convenient in that regard. Compile features are a very good hint, so far I've just used the sledgehammer variant of requiring a certain standard via CMAKE_CXX_STANDARD_REQUIRED; also it's good to know that there are individual and composable pybind11 targets that can be used instead of pybind11_add_module for a more fine-grained setup. Guess I should have read the documentation a bit more carefully. 🙂

Regarding compatible interfaces, I would guess that position independent code generation is only required for our extension code if someone wanted to link against it downstream. I've made sure that pretty much all c++ code is header-only so that shouldn't be a problem.

Thanks again, I am amazed by the detail of your responses!

[henryiii]

The guide https://cliutils.gitlab.io/modern-cmake/ might be useful, and https://iscinumpy.gitlab.io/post/scikit-build-proposal/ gives our plan for Scikit-build, though I don't know if that will get funded. You can use cmake_args= to set CMAKE_ARGS (and in the latest development branch, CMAKE_ARGS works as an alternate spelling for SKBUILD_CONFIGURE_OPTIONS).

[clonker]

I've browsed through the guide and it looks very useful to me, thanks @henryiii ! For what it's worth I have taken the leap and set our project up to use skbuild under the hood. Works very well, I just had a caching issue when setting it up because of dual pip/conda distribution. Only one last sore point remains for me and that is testing: we use catch2 for some direct c++ tests and conan to pull it on demand which isn't really ideal I guess.

[xuhancn]

This issue is caused by the compiler(gcc) use the new cxxabi. And it runs on legacy cxxabi libstdc++ shared library.

From the gcc source code. We can found this function (_ZNSt15__exception_ptr13exception_ptr10_M_releaseEv) is belong to CXXABI_1.3.12

The legacy cxxabi libstdc++ shared library doesn't contains this function. It reports error.

You can check the gcc's libstdcxx abi by command:

gcc -v

The detailed from this configure(--with-default-libstdcxx-abi) is below:

Using a compiler, which built with "--with-default-libstdcxx-abi=gcc4-compatible" can solve this issue.

[WhiteWolf47]

I'm using langchain and i'm getting this error, anyone got any idea bout this?

[OlivierBinette]

@WhiteWolf47 Try installing and using gcc and g++ version 9 or 10. That works for me on Ubuntu 22.

[WhiteWolf47]

@WhiteWolf47 Try installing and using gcc and g++ version 9 or 10. That works for me on Ubuntu 22.

i tried using version 9 but still got the same error

[smashfan]

@WhiteWolf47尝试安装和使用 gcc 和 g++ 版本 9 或 10。这对我在 Ubuntu 22 上有效。

我尝试使用版本 9 但仍然遇到相同的错误

你找到解决方法了吗

[ventusff]

I encountered this error after running sudo do-release-upgrade to upgrade from Ubuntu20 (with pre-existing conda envs) to Ubuntu22.

After removing the old conda env and creating a new one with the exact same package versions in the newly upgraded Ubuntu22, the error no longer appears.

I suspect that the old conda env contains certain basic libraries suitable for Ubuntu20 but not for Ubuntu22. Recreating a new env installs new basic libraries suitable for Ubuntu22 and hence solve the problem.

[mavisguan]

I encountered this error after running sudo do-release-upgrade to upgrade from Ubuntu20 (with pre-existing conda envs) to Ubuntu22.

After removing the old conda env and creating a new one with the exact same package versions in the newly upgraded Ubuntu22, the error no longer appears.

I suspect that the old conda env contains certain basic libraries suitable for Ubuntu20 but not for Ubuntu22. Recreating a new env installs new basic libraries suitable for Ubuntu22 and hence solve the problem.

I tried gcc version 9 and 10 but got the same error. This worked for me! Thanks!

[Ender-William]

I encountered this error after running sudo do-release-upgrade to upgrade from Ubuntu20 (with pre-existing conda envs) to Ubuntu22.
After removing the old conda env and creating a new one with the exact same package versions in the newly upgraded Ubuntu22, the error no longer appears.
I suspect that the old conda env contains certain basic libraries suitable for Ubuntu20 but not for Ubuntu22. Recreating a new env installs new basic libraries suitable for Ubuntu22 and hence solve the problem.

I tried gcc version 9 and 10 but got the same error. This worked for me! Thanks!

I'm now using Ubuntu 22.04 with gcc 11.4, but got the same error, I have no idea how can i solve this problem.

[navieraintegral]

I don't know if the issue was fix it, but in my case I had the same issues, and resolved deleting version conda 3.5, share the versions I used:

1.- re-installing conda 24.1.2,
2.- Python 3.11.8,
3.- Gcc 11.4
4.- ubuntu 22.04

[RoundedOrange]

I don't know if the issue was fix it, but in my case I had the same issues, and resolved deleting version conda 3.5, share the versions I used:

1.- re-installing conda 24.1.2, 2.- Python 3.11.8, 3.- Gcc 11.4 4.- ubuntu 22.04

Thank you for your helpful suggestion! My conda version is also 3.5 and I encounter similar problem. After re-installing conda 24.2.1, my code can run normally. I think maybe different conda version is the cause for the bug...