Absolute LC_RPATH in libjpeg bundled with the Pillow 13.0.0 macOS arm64 wheel

[baldanzoso-w]

Hi Pillow maintainers, I have a packaging question about this official PyPI wheel:

• Wheel: pillow-13.0.0-cp312-cp312-macosx_11_0_arm64.whl
• SHA-256: fc481f742ccda20e9ed760b8f978dff50f2a4e9bc253ac167fb0a05b0783ef52

Static inspection of PIL/.dylibs/libjpeg.62.4.0.dylib shows an LC_RPATH entry for /Users/runner/work/Pillow/Pillow/build/deps/darwin/lib. This is a load-command observation, not a report that the path was accessed at runtime.

Is that build-time path intentionally retained in the published wheel? Is there a supported official build for CPython 3.12 on macOS arm64 that omits it?

Thanks for any clarification.

[hugovk]

I don't think it's intentional as such, rather a byproduct of the build setup.

Does it cause any problems?

No, there's no other official builds, the wheels on PyPI for Pillow are the official ones.

Another option is to build your own from source.

[baldanzoso-w]

Thanks for clarifying. We have not observed a runtime failure or an access to that path. The question came up because our packaging check flags absolute build-machine paths left in published binaries. Would you consider removing this build-time LC_RPATH from a future official macOS wheel, or is there already an issue or PR tracking that cleanup? No separate build is needed for this request.

[hugovk]

This would need reporting to https://github.com/matthew-brett/delocate, but if it's not a problem, I'd suggest configuring your packaging scanner not to flag this.