JuliaPy / JuliaPy/PythonCall.jl
Fixing incorrect "Unable to load"/"GLIBCXX not found" issue, once and for all (hopefully)
- 主要言語
- Julia
- スター
- 1.1k
- フォーク
- 86
- 平均マージ
- 1日 22時間
- マージ済み PR(30日)
- 3
説明
**Affects:** Both
**Describe the bug**
This is a bug that has plagued PyCall/PyJulia for a while and it seems the same issue occurs with PythonCall/juliacall. I've been discussing potential solutions with @mkitti for a while and am curious to hear what others think, in particular @cjdoris.
Basically, depending on your particular environment, you might see the following:
```python
In [1]: import sklearn # Triggers load of incompatible libstdc++
In [2]: from juliacall import Main as jl
ERROR: Unable to load dependent library /home/mc2473/.julia/juliaup/julia-1.10.0+0.x64.linux.gnu/lib/julia/libjulia-codegen.so.1.10
Message:/lib64/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /home/mc2473/.julia/juliaup/julia-1.10.0+0.x64.linux.gnu/lib/julia/libjulia-codegen.so.1.10)
```
which crashes Python without providing any useful debug information. This issue is related to https://github.com/JuliaPy/PythonCall.jl/issues/255 which has been addressed in the [documentation](https://juliapy.github.io/PythonCall.jl/stable/faq/#ccall-requires-the-compiler-error-when-importing-some-Python-libraries) (as well as the PyJulia docs [here](https://pyjulia.readthedocs.io/en/stable/troubleshooting.html#error-due-to-libstdc-version)).
In my opinion this is a really sharp corner of Python<->Julia interfaces, making them significantly less practical for end-users. I would really like to find a way to automatically solve this.
The simplest way to fix it is to preload the correct libstdc++ when starting Python, for example:
```bash
LD_PRELOAD=$HOME/.julia/juliaup/julia-1.10.0+0.x64.linux.gnu/lib/julia/libstdc++.so.6 ipython
```
Which is enough to solve the issue entirely. However this is not effective generally as you have to define it before python even starts.
The other solution is to import julia as early as possible. However, again, this is not a general solution as the julia import might occur deep in some dependency that an inexperienced end-user is simply not aware of.
So I'm wondering what options we have to actually fix this, once and for all (hopefully), so that an end-user won't have to run into this ever again. Maybe:
1. Can we replace the loaded libstdc++ at runtime to the "correct" one as installed by julia?
2. Can we load two versions of libstdc++ into Python at once? (Is that possible?)
3. Can we install a static version of the relevant Julia libraries?
4. Can we check, in advance, whether there will be a `GLIBCXX` issue, and prevent the Python hard crash – maybe using the opportunity to directly provide debugging information to the user?
What do you think?
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
Start by reproducing the sklearn import followed by `from juliacall import Main as jl`, and review the linked PythonCall issue and the documented PyCall/PyJulia troubleshooting guidance. Done means identifying a reliable way to avoid the hard crash or provide useful diagnostics for the incompatible `GLIBCXX`/libstdc++ condition without requiring users to set `LD_PRELOAD` first.
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- julia, python
- 領域
- backend-api-design
- issue の種類
- バグ
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100