BUG: downstream testing failures on ubuntu+conda due to libstdc++.so.6 linkage issue #238
Open
1 task done
Labels
Comments
|
Here are the
|
|
I have collected a list of the dependencies that changed from 2 days ago (working) to 1 day ago (broken): < libgfortran-ng-12.2.0 | h69a702a_19 22 KB conda-forge
> libgfortran-ng-13.1.0 | h69a702a_0 23 KB conda-forge
< libgfortran5-12.2.0 | h337968e_19 1.8 MB conda-forge
> libgfortran5-13.1.0 | h15d22d2_0 1.4 MB conda-forge
< libssh2-1.10.0 | hf14f497_3 234 KB conda-forge
> libssh2-1.11.0 | h0841786_0 265 KB conda-forge
< libstdcxx-ng-12.2.0 | h46fd767_19 4.3 MB conda-forge
> libstdcxx-ng-13.1.0 | hfd8a6a1_0 3.7 MB conda-forge |
|
Thanks for the additional information. I would have guessed as well from looking at the environments that libstdcxx 13 is responsible somehow (not least because I had done the PR that updated this). At first I thought it might have bumped the SOVER, but that's not the case. Still, could you try a run with |
|
Confirmed everything looks to be working with |
|
OK. I'm going to see if the same issue appears on this feedstock (as it's essentially a scipy issue). Still, your log message either looks corrupted (encoding issues --> mojibake?), or something else is going very wrong: We do have: present for libstdcxx-ng 13.1 (and the picture fore 12.4 is the same, except it's 6.0.30 instead of .31, but that's normal) |
|
There are no problems using scipy 1.10.1 with libstdcxx-ng 13.1 in #240... Your issues may be an artefact of pysr's build process (I mention this because it seems to be reinstalling numpy, not sure what it's doing with scipy -- though this is pure speculation). |
This was referenced Jun 12, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Solution to issue cannot be found in the documentation.
Issue
Starting last night, I started seeing downstream CI testing failures on Ubuntu, across all Python versions tested (3.8, 3.9, 3.10, 3.11). One example is given here: https://github.com/MilesCranmer/PySR/actions/runs/5168482287. This installation method tests whether a
conda-forgeinstalled version ofpysr(which hasscipyas an indirect dependency) is working. I test bothmambaandcondaas well but this does not change the behavior. This is otherwise a very stable set of tests, with occasional failures on a single OS+Python version. But it is unprecedented to see all Python versions fail in sync like this.This might not be due to a change in
scipy, but a change in a dependency that breaks the linkage to libstdc++. However, whatever change happened currently breaks the scipy build on ubuntu+conda, across all python versions.These are the dependencies of PySR:
Of these, only scikit-learn directly depends on scipy.
Reproducing Code Example
Error message
Run python -m pysr.test main python -m pysr.test main shell: /usr/bin/bash -l {0} env: INPUT_RUN_POST: true CONDA: /usr/share/miniconda3 CONDA_PKGS_DIR: /home/runner/conda_pkgs_dir ERROR: Unable to dlopen(cxxpath) in parent! Message: /usr/share/miniconda3/envs/pysr-test/lib/python3.10/site-packages/scipy/sparse/../../../../libstdc++.so.6GB?`�: cannot open shared object file: No such file or directoryAdditional info
Here is the recipe file that PySR uses:
https://github.com/conda-forge/pysr-feedstock/blob/6b5be685bf409af2304d18b94181db87c7c90843/recipe/meta.yaml#L28-L38
with the relevant conda dependencies here:
The output of
conda infoandconda listare given here.Originally posted to scipy/scipy#18626
The text was updated successfully, but these errors were encountered: