"Fetchinson . via Python-list" <python-list@python.org> writes:
> I'm trying to install a binary package (tensorflow) which contains
> some binary C extensions. Now my system glibc is 2.15 but the binaries
> in the C extensions were created (apparently) with glibc 2.17. So I
> thought no problemo I installed glibc 2.17 to a custom location, built
> python2.7 from source (hopefully using my custom glibc) and installed
> pip and everything else using this custom built python. But still when
> I try to import tensorflow I get:
>
> ImportError: /lib64/libc.so.6: version `GLIBC_2.17' not found
> (required by
> /home/nogradi/fetch/custom/lib/python2.7/site-packages/tensorflow/python/_pywrap_tensorflow_internal.so)
>
> So apparently it's trying to use my system glibc, not the custom one.
>
> How do I tell this extension to use the custom glibc? Is it even possible?
When you import a C extension, a variant of the linker ("ld")
is used to make the linkage between the open references in
the C extension and its (now) embedding environment.
You can use the envvar "LD_LIBRARY_PATH" (using the typical path
syntax) to tell the linker where it can look for general
shared objects (such as "glibc.so").
There is also a linker command line option to tell such information
when the shared object (corresponding to the C extension) is
build.
> But maybe I have an even more basic issue: how do I link python not
> with the system glibc but with my custom glibc?
Again, you could use the "LD_LIBRARY_PATH" envvar.
There may be a way to specify the information also for the
"configure" (generating the makefiles for the Python build process).
--
https://mail.python.org/mailman/listinfo/python-list
