# GLIBCXX version not found

**URL:** <https://discourse.julialang.org/t/glibcxx-version-not-found/82209>\
**Category:** General Usage\
**Created:** [June 3, 2022, 7:30pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209 "2022-06-03T19:30:27Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![Clemapfel](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/clemapfel/32/32261_2.png) [@Clemapfel](https://discourse.julialang.org/u/Clemapfel)\
**Post date:** [June 3, 2022, 7:30pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/1 "2022-06-03T19:30:27Z")

</div>

Hi, I have a shared C library I compiled myself. When trying to `ccall` in Julia, it throws the following error:

```julia
julia> ccall((:test, "./<...>.so"), Cvoid, ())
ERROR: could not load library "./<...>.so"
/home/redacted/Applications/julia-1.8.0-beta3/bin/../lib/julia/libstdc++.so.6: 
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?

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [June 3, 2022, 9:14pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/2 "2022-06-03T21:14:36Z")

</div>

I’m (slowly) working on it.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [June 3, 2022, 9:15pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/4 "2022-06-03T21:15:56Z")

</div>

Side note

> [@Clemapfel](#):
>
> I have a shared C library I compiled myself.

I doubt it’s pure C if you have `GLIBCXX` symbols.

---

<div class="post-metadata">

**Author:** ![daharn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/daharn/32/27088_2.png) [@daharn](https://discourse.julialang.org/u/daharn)\
**Post date:** [August 17, 2022, 12:38pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/6 "2022-08-17T12:38:05Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![gbaraldi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gbaraldi/32/22101_2.png) [@gbaraldi](https://discourse.julialang.org/u/gbaraldi)\
**Post date:** [August 17, 2022, 12:42pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/7 "2022-08-17T12:42:43Z")

</div>

We have to update our libstdc++ which is ongoing work. 🙂

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [August 17, 2022, 1:37pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/8 "2022-08-17T13:37:44Z")

</div>

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

```julia
if VERSION <= v"1.6.2"
    # GLIBCXX_3.4.26
    cxx_version = ">=3.4,<9.2"
else
    # GLIBCXX_3.4.29
    cxx_version = ">=3.4,<11.4"
end

CondaPkg.add("libstdcxx-ng", version=cxx_version)

```

borrowing from [https://github.com/cjdoris/PythonCall.jl/compare/main..cxx-compat#diff-22bffae9c7708a5fa205669c9c428ac479d0e9ea2a7ae6a867bae5a89a0f353dR55-R73](https://github.com/cjdoris/PythonCall.jl/compare/main..cxx-compat#diff-22bffae9c7708a5fa205669c9c428ac479d0e9ea2a7ae6a867bae5a89a0f353dR55-R73). See also [Add constraints from julia process into Conda version resolution (somehow?) · Issue #43 · cjdoris/CondaPkg.jl · GitHub](https://github.com/cjdoris/CondaPkg.jl/issues/43) for a discussion of how to fix this for PythonCall. Probably there’s a way to do this with PyCall as well.

Also, as discussed there, I think scipy v1.9 introduced a dependence on a later gcc version, so one can also try just making sure they are using scipy v1.8.

---

<div class="post-metadata">

**Author:** ![daharn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/daharn/32/27088_2.png) [@daharn](https://discourse.julialang.org/u/daharn)\
**Post date:** [August 17, 2022, 2:15pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/9 "2022-08-17T14:15:54Z")

</div>

> [@gbaraldi](#):
>
> We have to update our libstdc++ which is ongoing work. 🙂

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.

> [@ericphanson](#):
>
> Also, as discussed there, I think scipy v1.9 introduced a dependence on a later gcc version, so one can also try just making sure they are using scipy v1.8.

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.

---

<div class="post-metadata">

**Author:** ![ericphanson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ericphanson/32/215186_2.png) [@ericphanson](https://discourse.julialang.org/u/ericphanson)\
**Post date:** [August 17, 2022, 2:20pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/10 "2022-08-17T14:20:57Z")

</div>

> [@daharn](#):
>
> 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.

Yeah, I agree that always updating Julia doesn’t sound like the right fix. I think the right fix is to use whatever constraints Julia imposes on the environment in the version resolution of the python packages. That’s exactly why I filed [Add constraints from julia process into Conda version resolution (somehow?) · Issue #43 · JuliaPy/CondaPkg.jl · GitHub](https://github.com/cjdoris/CondaPkg.jl/issues/43).

> [@daharn](#):
>
> 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.

Yes, I would use PythonCall instead which does.

---

<div class="post-metadata">

**Author:** ![daharn](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/daharn/32/27088_2.png) [@daharn](https://discourse.julialang.org/u/daharn)\
**Post date:** [August 17, 2022, 2:22pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/11 "2022-08-17T14:22:33Z")

</div>

> [@ericphanson](#):
>
> Yes, I would use PythonCall instead which does.

Good advice, I will look into this!

---

<div class="post-metadata">

**Author:** ![cjdoris](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cjdoris/32/213133_2.png) [@cjdoris](https://discourse.julialang.org/u/cjdoris)\
**Post date:** [August 17, 2022, 7:42pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/12 "2022-08-17T19:42:43Z")

</div>

Indeed, if I get around to merging that branch and making a release of PythonCall, this issue should be a thing of the past - it will be silently fixed for you.

---

<div class="post-metadata">

**Author:** ![t-bltg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/t-bltg/32/25526_2.png) [@t-bltg](https://discourse.julialang.org/u/t-bltg)\
**Post date:** [November 22, 2022, 2:36pm UTC](https://discourse.julialang.org/t/glibcxx-version-not-found/82209/13 "2022-11-22T14:36:47Z")

</div>

Here is a workaround for `Conda / PyCall / PyPlot` (used in `Plots` ci), before we can transition to `CondaPkg / PythonCall / PythonPlot`:

> <https://github.com/JuliaPlots/Plots.jl/blob/871aeb044dc0aa1a04364d6adc060811317868c4/.github/workflows/ci.yml#L68-L82>