No it won’t help PyCall. I don’t think it does any special handling of library versions.
There are three libstdc++ libraries involved:
- the system one
- the one shipped by Julia
- the one required by the python packages
Since v1.7 (I think, I’m going by memory), at startup julia checks the version of the system libstdc++, if that’s newer than the one shipped by Julia, then that one is loaded, otherwise Julia loads the one it ships. If the system one was new enough, then you wouldn’t have problems, hence my comment. However, in the Conda ecosystem someone thought it was a good idea to compile libraries with a super recent compiler (narrator: for compatibility that’s a dreadful idea), so if you try to load such library in a process with an older libstdc++ (and by “old” I mean 2-year old, not something from last decade) then you get an error, that’s why the solution for you was to require Conda to use libstdc++ before gcc v14.
For the record, in the Julia ecosystem we compile C++ libraries with older libstdc++, and ship in Julia a newer one: this maximise compatibility and reduces the likelihood of these issues when our libraries are involved.
My guess is that you now got a newer build of matplotlib.
Numpy is written in C only as far as I remember, it doesn’t link to libstdc++ at all.
Indeed, somehow matplotlib got upgraded.
Thank you for the explanation about the libstdc++. I never thought about these before. The system uses GCC 8.5, so I guess Julia ships a newer but not the latest libstdc++, which caused the error.
PythonCall v0.9.27 is released with the fix for this - upgrade and you should get a compatible matplotlib.