delocate-wheel sets invalid relative paths to delocated dylibs (related to "purelib" subdirectory) #149
Comments
|
I know this bug report is a bit old but came across this today whilst packaging an existing CMake project into a wheel. It hapens because |
|
I tried setting the rpath manually in CMake, but I noticed that delocate removes this rpath and installs its own. Is there any way to bypass this? # Scikit-build installs MOAB to ${SKBUILD_PLATLIB_DIR}/pymoab/core
# So, set bin directory to root environment (install prefix/bin)
set(CMAKE_INSTALL_BINDIR ${SKBUILD_SCRIPTS_DIR})
set(CMAKE_INSTALL_DATADIR ${SKBUILD_DATA_DIR}/${CMAKE_INSTALL_DATADIR})
set(CMAKE_INSTALL_DOCDIR ${SKBUILD_DATA_DIR}/${CMAKE_INSTALL_DOCDIR})
set(CMAKE_INSTALL_MANDIR ${SKBUILD_DATA_DIR}/${CMAKE_INSTALL_MANDIR})
set(SKBUILD_LIB_DIR ${CMAKE_INSTALL_LIBDIR}/python${Python_VERSION_MAJOR}.${Python_VERSION_MINOR}/site-packages/pymoab/core/${CMAKE_INSTALL_LIBDIR})
# Auditwheel and Delocate need this when repairing the wheel
# Since MOAB libs are installed in the pymoab/core subdirectory
# Auditwheel and Delocate need this to find the MOAB libs for pymoab.data
# It's a bit of a hack, but it works
set(SKBUILD_REPAIR_WHEEL_PATCH pymoab/core/${CMAKE_INSTALL_LIBDIR})
if(APPLE)
set(PYMOAB_LIBRARY_RPATH "@loader_path")
set(PYMOAB_PYTHON_MODULE_RPATH "@loader_path/core/${CMAKE_INSTALL_LIBDIR}")
set(PYMOAB_BINARY_RPATH "@loader_path/../${SKBUILD_LIB_DIR};@loader_path/../../${SKBUILD_REPAIR_WHEEL_PATCH}")
elseif(UNIX)
set(PYMOAB_LIBRARY_RPATH "$ORIGIN")
set(PYMOAB_PYTHON_MODULE_RPATH "$ORIGIN/core/${CMAKE_INSTALL_LIBDIR}")
set(PYMOAB_BINARY_RPATH "$ORIGIN/../${SKBUILD_LIB_DIR};$ORIGIN/../${SKBUILD_REPAIR_WHEEL_PATCH};$ORIGIN/../../${SKBUILD_REPAIR_WHEEL_PATCH}")
endif() |
|
https://packaging.python.org/en/latest/specifications/binary-distribution-format/ What is the quickest way to generate a wheel with the Possible solution: From |
|
Something I've noticed is the package is in I'm curious to know which tool is building wheels like this. |
Describe the bug / To Reproduce
My original wheel contains these files:
It depends on Boost, ICU, and PCRE, which have been installed via Homebrew:
I call
delocate-wheellike this:The dylibs are properly copied into the delocated wheel:
The output of
delocate-listdepslooks reasonable at first sight:However,
otool -Lshows me these relative paths:Note all the relative paths
@loader_path/../../../PyMyLib.dylibs. While these match the files as they are placed inside the wheel archive, afterpip installthese relative paths don't point to the dylibs under site-packages:Note how
PyMyLib.cpython-39-darwin.soand__init__.pyhave been installed directly toPyMyLib/, not toPyMyLib-0.1.17.data/purelib/PyMyLib/(as it looks in the wheel archive).Consequently, I get import errors because the dynamic libraries are not found:
Expected behavior
delocate-wheelshould set relative paths to dylibs in such a way that they agree with their ultimate location afterpip install.Wheels used
Unfortunately not open source. But the
__init__.pycontains just these lines:Platform (please complete the following information):
Additional context
I actually don't know why our (cmake-based) build process produces wheels with these subdirectories
PyMyLib-0.1.17.data/purelib. Pointers that could help me simplify that would also be appreciated. 🙂The text was updated successfully, but these errors were encountered: