JuliaPy / JuliaPy/PythonCall.jl

Fixing incorrect "Unable to load"/"GLIBCXX not found" issue, once and for all (hopefully)

Ouverte
#437 7 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
bug
Langage dominant
Julia
Étoiles
1.1k
Forks
86
Merge moyen
1 j 22 h
PR mergées (30 j)
3

Description

**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?

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
julia, python
Domaine
backend-api-design
Type d'issue
Bug
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
25/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.