Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

During CI testing: Unable to dlopen(cxxpath) in parent! cannot open shared object file: File name too long #2455

Closed
rwest opened this issue Jun 5, 2023 · 2 comments

Comments

@rwest
Copy link
Member

rwest commented Jun 5, 2023

Bug Description

The build-documentation continuous integration run at https://github.com/ReactionMechanismGenerator/RMG-Py/actions/runs/5180345336 failed when running sphinx with the log:

Running Sphinx v5.0.2
making output directory... done
building [mo]: targets for 0 po files that are out of date
building [html]: targets for 206 source files that are out of date
updating environment: [new config] 206 added, 0 changed, 0 removed
reading sources... [  0%] contents
reading sources... [  0%] latex-api
reading sources... [  1%] latex-rmg
reading sources... [  1%] reference/arkane/common
ERROR: Unable to dlopen(cxxpath) in parent!
Message: /usr/share/miniconda3/envs/rmg_env/lib/python3.7/site-packages/rdkit/../../../libstdc++.so.6nts a live Julia runtime.

        Note: Use `LibJulia` to fully control the initialization of
        the Julia runtime.

        Parameters
        ==========

        init_julia : bool
            If True, try to initialize the Julia runtime. If this code is
            being called from inside an already running Julia, the flag should
            be passed as False so the interpreter isn't re-initialized.

            Note that it is safe to call this class constructor twice in the
            same process with `init_julia` set to True, as a global reference
            is kept to avoid re-initializing it. The purpose of the flag is
            only to manage situations when Julia was initialized from outside
            this code.

        runtime : str
            Custom Julia binary, e.g. "/usr/local/bin/julia" or "julia-1.0.0".

        debug : bool
            If True, print some debugging information to STDERR
: cannot open shared object file: File name too long
Error: Process completed with exit code 1.

I can't see what has changed to cause it, so I am attempting to just restart the job and see what happens.

and shortly after that, this build-and-test job failed in a similar way
https://github.com/ReactionMechanismGenerator/RMG-Py/actions/runs/5180282876/jobs/9334261409#step:9:39

run make test-unittests
  make test-unittests
  shell: /usr/bin/bash -l {0}
  env:
    RMG_DATABASE_BRANCH: main
    INPUT_RUN_POST: true
    CONDA: /usr/share/miniconda3
    CONDA_PKGS_DIR: /home/runner/conda_pkgs_dir
    PYTHONPATH: /home/runner/work/RMG-Py/RMG-Py/RMG-Py:
nosetests --nocapture --nologcapture --all-modules -A 'not functional' --verbose --with-coverage --cover-inclusive --cover-erase --cover-html --cover-html-dir=testing/coverage --exe rmgpy arkane
ERROR: Unable to dlopen(cxxpath) in parent!
Message: /usr/share/miniconda3/envs/rmg_env/lib/python3.7/site-packages/scipy/sparse/../../../../libstdc++.so.6 Julia runtime.

        Note: Use `LibJulia` to fully control the initialization of
        the Julia runtime.

        Parameters
        ==========

        init_julia : bool
            If True, try to initialize the Julia runtime. If this code is
            being called from inside an already running Julia, the flag should
            be passed as False so the interpreter isn't re-initialized.

            Note that it is safe to call this class constructor twice in the
            same process with `init_julia` set to True, as a global reference
            is kept to avoid re-initializing it. The purpose of the flag is
            only to manage situations when Julia was initialized from outside
            this code.

        runtime : str
            Custom Julia binary, e.g. "/usr/local/bin/julia" or "julia-1.0.0".

        debug : bool
            If True, print some debugging information to STDERR
: cannot open shared object file: File name too long
make: *** [Makefile:64: test-unittests] Error 1
Error: Process completed with exit code 2.

How To Reproduce

Opened a pull request. The CI failed.

Installation Information

Describe your installation method and system information.

  • OS: The documentation test CI runs on Ubuntu-latest
  • Installation method: from source (via CI)
  • RMG version information: latest (running on CI)

Additional Context

It looks a bit like
scipy/scipy#18626
and
conda-forge/scipy-feedstock#238

@mjohnson541
Copy link
Contributor

I ran into this this weekend as well here: #2316

@rwest
Copy link
Member Author

rwest commented Jun 5, 2023

Hao-Wei also noted it in https://github.com/ReactionMechanismGenerator/RMG-Py/actions/runs/5178850611/jobs/9330889633?pr=2446

In slack Jackson suggested trying ubuntu-20.04 instead of ubuntu-latest which is in progress on pull request
#2456

He also noted

and/or this is the likely issue:
libstdcxx-ng 13.1.0 hfd8a6a1_0 conda-forge
from the resolved environment on the run that Hao-Wei linked, can we also try setting libdtscxx-ng<13 in the environment.yml file

@rwest rwest closed this as completed in 211f034 Jun 7, 2023
JacksonBurns added a commit to JacksonBurns/RMG-Py that referenced this issue Jun 15, 2023
…cxx-ng patches)

a new version of Julia has been released that fixes the issue we were facing, so these changes are no longer needed (see issue ReactionMechanismGenerator#2455 and PR ReactionMechanismGenerator#2456)
rwest added a commit that referenced this issue Jun 15, 2023
…file

We had been patching the environment file to force a libstdcxx-ng version <13 
(see issue #2455 and PR #2456).
Since then a new version of Julia has been released that fixes the issue we were facing, 
so these changes are no longer needed.  
Also adds version Julia (1.9.0) to the "do not allow" list for the environment file. 
We could probably find a way to specifically disallow the problematic build instead, but this is easier.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants