Hi, I have a shared C library I compiled myself. When trying to ccall in Julia, it throws the following error:
julia> ccall((:test, "./<...>.so"), Cvoid, ())
ERROR: could not load library "./<...>.so"
version `GLIBCXX_3.4.30' not found (required by /home/redact/Workspace/<...>/build/<...>.so)
Calling strings ~/Applications/julia-1.8.0-beta3/lib/julia/libstdc++.so | grep GLIBCXX_3.4. indeed confirms that the highest GLIBCXX available to julia is GLIBCCXX_3.4.29, not 30.
On my own system I can obviously just copy my systems libstdc++.so into Julias folder, which fixes the error. However, most of my users willl be using a shipped-with-julia libstdc++.so library that may be even older than 3.4.29.
What is the accepted way of addressing this without modifying the local Julia library folder? How can I tell Julia to use a newer one?
I have a similar problem when importing some Python packages via PyCall that use their own binaries which are linked to a different libstdc++ version. The underlying issue seems to be tied to the fact that Julia always loads its own libstdc++ library on startup which might be older than binaries coming from another source expect it to be.
Can you elaborate a little more on how you plan to solve this?
As a shorter-term fix (that doesn’t require updating Julia), one can try to arrange the python libraries they use to use the same gcc version as Julia was compiled with. If you are using CondaPkg on Linux, this looks like
if VERSION <= v"1.6.2"
cxx_version = ">=3.4,<9.2"
cxx_version = ">=3.4,<11.4"
Yes, but this will force everyone to update Julia which might not be desired. I consider it unfortunate that all binary packages buried in anything that is imported into Julia will have to work with whatever binaries where shipped with Julia, even if they actually provide their own as is the case with all conda packages. However, I don’t know if this can be avoided.
Yes, this is my temporary solution to this. However, there might be thousands of these kind of issues with other conda packages. Essentially, this requires everyone using Conda within Julia to regularly update to the newest Julia version as soon as it is available and then hope that the conda binaries do not “catch up” to Julia’s too fast.
This is additionally enforced by the fact that afaik PyCall currently does not support distinct python environments which would allow more convenient pining of conda packages to specific versions.