pystan: Compilation crashes with `undefined symbol: _ZSt28__throw_bad_array_new_lengthv` (Fedora 34, gcc 11)

After installing pystan and running the 8schools example, the compilation crashes with error message

ImportError: /home/solant/.cache/httpstan/4.4.2/models/sk7xw5y6/stan_services_model_sk7xw5y6.cpython-37m-x86_64-linux-gnu.so: undefined symbol: _ZSt28__throw_bad_array_new_lengthv

I’m running Fedora 34, I tried both the most recent python version and 3.7.10. Any idea what’s wrong? I couldn’t find anything by googling the above error.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 21 (5 by maintainers)

Commits related to this issue

Most upvoted comments

@joshua-cogliati-inl’s work around is functional.

It’s probably better to make modification in the virtual environment one is using to back-up previous shared objects:

cd $CONDA_PREFIX/envs/your_env/lib

# Verify that `_ZSt28__throw_bad_array_new_lengthv` is missing in the target shared object
objdump -T libstdc++.so.6.0.28 | grep throw_bad_array

# Back-up the target shared object
mv libstdc++.so.6.0.28 libstdc++.so.6.0.28.old

# Change the target to point on the system's 
ln -s /usr/lib64/libstdc++.so.6.0.29 libstdc++.so.6.0.28

I think this is the GCC commit that is causing this problem: https://github.com/gcc-mirror/gcc/commit/f92a504fdd943527687faf9557e0b39ff7fe6125

And basically, conda has libstdc++.so.6.0.28 but fedora 34 has libstdc++.so.6.0.29:

objdump -T /usr/lib64/libstdc++.so.6.0.29  | grep throw_bad_array
00000000000a423f g    DF .text  0000000000000035  GLIBCXX_3.4.29 _ZSt28__throw_bad_array_new_lengthv
00000000000a14ee g    DF .text  0000000000000035  CXXABI_1.3.8 __cxa_throw_bad_array_new_length
00000000000a13d3 g    DF .text  0000000000000033  CXXABI_1.3.8 __cxa_throw_bad_array_length

 objdump -T libstdc++.so.6.0.28 | grep throw_bad_array
00000000000a9e5d g    DF .text  000000000000002f  CXXABI_1.3.8 __cxa_throw_bad_array_new_length
00000000000a9dd0 g    DF .text  000000000000002f  CXXABI_1.3.8 __cxa_throw_bad_array_length

A temporary workaround until conda gets an updated libstdc++ is to go into your miniconda directory and force it to use the system libstdc++:

cd  ~/miniconda3/lib/
rm libstdc++.so libstdc++.so.6
ln -s /usr/lib64/libstdc++.so.6.0.29 libstdc++.so
ln -s /usr/lib64/libstdc++.so.6.0.29 libstdc++.so.6

Seems like people still come from Google over to this issue with conda-related compiler issues. Thus I wanted to give a piece of brief information on how to fix these problems.

  • conda environments are fully self-contained, i.e. they are meant to be working fully independent from your operating system
  • conda will ship a different libstdc++ from your system. The version depends on which source for your package you choose. There are two main distributions using the conda package manager: Anaconda and conda-forge. They use a similar setup but vary in the versions of packages they provide.
  • Nowadays (different to the issue here), the libstdc++ should be newer than the one on your OS. Thus you would see a linker error when compiling compared to the ImportError here.
  • Thus the conda environments/distributions come with their own compiler toolchain. You can install them using conda install c-compiler cxx-compiler / mamba install c-compiler cxx-compiler. This will then set the environment variables CC and CXX to the provided compiler and also set CFLAGS, CXXFLAGS, LDFLAGS to build and link against all libraries in the environment (including the libstdc++).

Thanks for the update. I’ll spin up a fedora 34 VM and see if I can find out what is wrong.