libstdcxx version-bounds #243
Conversation
samtkaplan
force-pushed
the
libcxxoption
branch
from
c4267ee to
481eb30
Compare
Co-authored-by: Elliot Saba <staticfloat@gmail.com>
| 28 => v"9.3.0", | ||
| 29 => v"11.1.0", | ||
| 30 => v"12.1.0", | ||
| 31 => v"13.1.0", |
There was a problem hiding this comment.
Looking at https://gcc.gnu.org/develop.html#timeline there are more versions of GCC than in that other linked page. If I understand right, I think it means that we could bump the mappings to 28 => 9.5.0, 29 => 11.3.0, 30 => 12.2.0.
There was a problem hiding this comment.
I went ahead and applied you suggestion. But, it isn't clear to me if the libstdc++ version is constant from, say, gcc 9.3.0->9.5.0
There was a problem hiding this comment.
The ABI Policy page says "If a particular release is not listed, it has the same version labels as the preceding release." I take that to mean that all releases >=9.3.0 and <10.1.0 have the same version labels.
| 31 => v"13.1.0", | ||
| ) | ||
| # Get the libstdcxx version that is currently loaded in this Julia process | ||
| loaded_libstdcxx_version = Base.BinaryPlatforms.detect_libstdcxx_version() |
There was a problem hiding this comment.
We need to gracefully handle the possibility that this returns nothing or a version other than 3.4.*.
There was a problem hiding this comment.
I added some code in the last commit (e7c8dac) that attempts to address this, but I'm not sure what the best solution is. In particular, if Julia is not able to detect the version, then we try to get the version bound from the user environment variable, and if the user has not set a variable, then do not inject a version bound. Hopefully the last case will be rare. Note that if the version is not 3.4.*, then detect_libstdcxx_version returns nothing (if I understood the code correctly).
src/cpython/context.jl
Outdated
| # the highest GCC version we know about, which should be a fairly safe choice. | ||
| max_version = get(vers_mapping, loaded_libstdcxx_version.patch, vers_mapping[maximum(keys(vers_mapping))]) | ||
| cxx_version = ">=3.4,<=$(max_version.major).$(max_version.minor)" | ||
| get(ENV, "JULIA_CONDAPKG_LIBSTDCXX_VERSION_BOUND", cxx_version) |
There was a problem hiding this comment.
Since this is an option to PythonCall, please rename the env var to JULIA_PYTHONCALL_....
|
This is really cool, I didn't know you could query the libstdc++ version like this! |
|
Great, thank you! |
|
@samtkaplan FYI I have moved this functionality into CondaPkg, so that PythonCall doesn't need to hackily add a new dependency at run-time - it instead depends on libstdcxx_ng at a special version "<=julia" which is now replaced by CondaPkg with an appropriate version (or removed entirely if not on Linux). The end result is the same. |
Hello,
We have run into a problem when using PythonCall with newer versions of TensorFlow. In particular, TensorFlow requires newer versions of libstdc++ than what is bundled with Julia. To partially solve this problem, we replace the bundled version of libstdc++ with the system (Ubuntu 22.04) version of libstdc++.
When using PythonCall and CondaPkg, PythonCall injects a version bound for libstdc++ into the conda operations. The version bound is determined by the version of libstdc++ bundled in Julia. In this PR, we find the bound at runtime, and allow the user to specify the version bound via an environment variable:
JULIA_CONDAPKG_LIBSTDCXX_VERSION_BOUNDJULIA_PYTHONCALL_LIBSTDCXX_VERSION_BOUND. For example, set the version bound via:Many thanks!
Fixes #237