JuliaPy / JuliaPy/PythonCall.jl
Fixing incorrect "Unable to load"/"GLIBCXX not found" issue, once and for all (hopefully)
- Lenguaje dominante
- Julia
- Estrellas
- 1.1k
- Forks
- 86
- Merge medio
- 1 d 22 h
- PR fusionados (30 d)
- 3
Descripción
**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?
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Línea de trabajo
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.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- julia, python
- Área
- backend-api-design
- Tipo de issue
- Error
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Estado de actividad
- Estancado
- Claridad
- Necesita aclaración
- Aptitud para principiantes
- 25/100