Rust binding in 3.4+ dynamically links with non-existent library

[dpage-edb]

The wheel for macOS includes _rust.abi3.so. This references a library that isn't shipped and has a path clearly from the build machine:

(foo) dpage@hal:~/git/pgadmin4/foo/lib/python3.8/site-packages/cryptography/hazmat/bindings$ otool -L _rust.abi3.so 
_rust.abi3.so:
	/Users/runner/work/cryptography/cryptography/cryptography-3.4.4/src/rust/target/release/deps/libcryptography_rust.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
	/usr/lib/libresolv.9.dylib (compatibility version 1.0.0, current version 1.0.0)

Whilst this may not break the package, it:

A) Is not good practice
B) Breaks build systems that automatically fixup library paths when creating relocatable appbundles.

B is the issue I'd like to see fixed, as the current situation requires me to modify code that's worked for many years (15+) to ignore errors when processing this particular file.

An additional issue, again likely benign for the general use case, is that _rust.abi3.so does not have the executable bit set as is generally the norm for shared libraries on *nix platforms. This also required me to change build code, as searches for binaries that need to be codesigned filtered possibly targets based on the executable bit, before doing further tests to see if the file was actually an executable or library (which gets very expensive without that check, in a codebase with thousands of Python/JS/HTML files etc).

Probably not relevant, but here's my system info:

(foo) dpage@hal:~/git/pgadmin4/foo/lib/python3.8/site-packages/cryptography/hazmat/bindings$ pip freeze
cffi==1.14.4
cryptography==3.4.4
pycparser==2.20
(foo) dpage@hal:~/git/pgadmin4/foo/lib/python3.8/site-packages/cryptography/hazmat/bindings$ python --version
Python 3.8.2
(foo) dpage@hal:~/git/pgadmin4/foo/lib/python3.8/site-packages/cryptography/hazmat/bindings$ pip --version
pip 21.0.1 from /Users/dpage/git/pgadmin4/foo/lib/python3.8/site-packages/pip (python 3.8)
(foo) dpage@hal:~/git/pgadmin4/foo/lib/python3.8/site-packages/cryptography/hazmat/bindings$ sw_vers -productVersion
11.1

Thanks!

[tiran]

Could you please clone the bug to https://github.com/PyO3/setuptools-rust? All magic happens inside the setuptool_rust package.

[dpage-edb]

Thanks, done: PyO3/setuptools-rust#106

[mathstuf]

The 3.4.6 release still has this problem because setuptools_rust has fixed the issue, but not released yet. Could this be reopened to track when wheels with viable library IDs will be available? Or should I use a new issue?

[reaperhulk]

Looks like there’s going to be a setuptools-rust release in the next few days which will resolve this.