You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When installing python wheels that contain native bits, the
Pipfile.lock will only contain artifact hashes for the architecture
that `pip lock` was run against, along with the source archive
hash. So when installing on a different architecture, pip will attempt
to compile from the source archive, and therefore will need the
appropriate development files for the native dependencies that are
used by the programs that it's compiling.
In this case, the h5py python package is needed in the tensorflow
images, and to compile the native shared object files that it contains
from source, the libhdf5.so file from hdf5-devel is needed. The
compiled object files will be dynamically linked to the .so files from
hdf5 (so technically the hdf5-devel is only needed at compile time,
then hdf5 at runtime, but since the compilation is only done on _some_
architectures, there isn't a dedicated build stage for these python
packages, so to try to make minimal changes, the -devel package is
left in place.
On the architecture that the Pipfile.lock was generated on (x86_64),
the native bits are downloaded pre-compiles as before. This makes
things a little weird, as on x86_64 we'll have .so files that are
precompiled and link to other .so files downloaded from PyPI, whereas
on aarch64 we'll have .so files that were compiled as part of the
build and linked to other .so files from hdf5 and other RPMs from the
system.
0 commit comments