PySR: [BUG]: libstdc++ issues / `GLIBCXX` not found

What happened?

Hi Miles, this is the issue flagged to you on Twitter – sorry it’s taken time to report, as I was drowning in exam meetings today!

The issue we saw was on a Centos7/RHEL system, which by default has Python 2.7 (or python3 = 3.6) and GCC 4.8.5 – too old for much development these days. So we source installed RH software collections from /opt/rh to overload these system defaults with Python 3.8 and GCC8. Usually works fine, at least for straightforward Python, C++, and compilation between them using the tools found in the environment.

But we hit a problem when installing PySR. juliaup install worked fine, but the python3 -m pysr install command failed with a GCLIBCXX_* version-symbol mismatch: usually the indication of a mismatch between the active compiler and the C++ stdlib being linked against. (I’m afraid I don’t have the direct terminal printouts handy: this happened yesterday when installing for a student, and we closed the terminal and moved on with installation on his Windows laptop.) Above the error message we could see the compile/link command explicitly using the system libstdc++ rather than the override from /opt/rh (e.g. /opt/rh/devtoolset-8/root/usr/lib/gcc/x86_64-redhat-linux/8/libstdc++.so) – again, I can provide the full output later if useful.

Seems to me that something in the pysr install code is not picking up the overloaded compiler/stdlib locations, maybe assuming that the system ones are valid. It’d be best to query the appropriate ones from the environment, but maybe there is a way around like exporting library-path variables while running the installer? Thanks!

Version

Latest from pip

Operating System

Linux

Package Manager

pip

Interface

Script (i.e., python my_script.py)

Relevant log output

TBC

Extra Info

No response

About this issue

Original URL
State: closed
Created a year ago
Comments: 26 (20 by maintainers)

Most upvoted comments

Ah, wait, I found this in the PyJulia docs:

Error due to ``libstdc++`` version

When you use PyJulia with another Python extension, you may see an error
like :literal:`version `GLIBCXX_3.4.22' not found` (Linux) or
``The procedure entry point ... could not be located in the dynamic link library libstdc++6.dll``
(Windows). In this case, you might have observed that initializing
PyJulia first fixes the problem. This is because Julia (or likely its
dependencies like LLVM) requires a recent version of ``libstdc++``.

Possible fixes:

-  Initialize PyJulia (e.g., by ``from julia import Main``) as early as
   possible. Note that just importing PyJulia (``import julia``) does
   not work.
-  Load ``libstdc++.so.6`` first by setting environment variable
   ``LD_PRELOAD`` (Linux) to
   ``/PATH/TO/JULIA/DIR/lib/julia/libstdc++.so.6`` where
   ``/PATH/TO/JULIA/DIR/lib`` is the directory which has
   ``libjulia.so``. macOS and Windows likely to have similar mechanisms
   (untested).
-  Similarly, set environment variable ``LD_LIBRARY_PATH`` (Linux) to
   ``/PATH/TO/JULIA/DIR/lib/julia`` directory. Using
   ``DYLD_LIBRARY_PATH`` on macOS and ``PATH`` on Windows may work
   (untested).

See: https://github.com/JuliaPy/pyjulia/issues/180,
https://github.com/JuliaPy/pyjulia/issues/223

Could you try those solutions?

MilesCranmer on Jun 14, 2023

Okay I think this is related to a very nasty bug we have been working on for the past week at the intersection of conda-forge, PyCall.jl, and the new version of libstdcxx-ng in conda-forge. See, e.g., https://github.com/conda-forge/scipy-feedstock/issues/238, https://github.com/conda-forge/pysr-feedstock/pull/89, https://github.com/JuliaPy/PyCall.jl/pull/1040, https://github.com/conda-forge/pysr-feedstock/pull/90.

Apologies for the delay in fixing this. Until the conda-forge job in PySR is listed as “passing” again, I would recommend one of two options:

Switch to the pip install of PySR, with a juliaup based install of Julia
Create a new conda environment with the constraint libstdcxx-ng<13:

conda create -n pysr pysr 'libstdcxx-ng<13' -c conda-forge

MilesCranmer on Jun 12, 2023