The current FFI bindings in zmq-sys/src/ffi.rs look like they have been generated on a x86_64 machine almost three years ago. This is creating two kinds of problems:
bugfixes from newer bindgen versions are not applied
the bindings hard-code 64-bit / x86-64 assumptions
For example, the bindings assume 64-bit pointer widths, which is not correct on 32-bit x86 (and 32-bit ARM). The proper way to handle this would be to re-generate the bindings at build time, by using the bindgen library interface in the build script.
This would also solve issue https://github.com/erickt/rust-zmq/pull/329 properly (not by providing different tests on different architectures, but by actually generating the bindings and tests on the target architecture itself).
If the need to have the zmq headers available at build time is not something desirable, then the functionality for regenerating the bindings could be behind an off-by-default feature, so at least people who need to regenerate the bindings can do so.
Two of the most prominent crates that use bindgen at build time handle this very flexibly:
For example, in all packages in Fedora Linux for Rust crates that provide bindings for C libraries, we need to turn on regenerating bindings at build time, since we provide binaries for various architectures (including 64-bit and 32-bit targets of x86 and ARM, and others), and we have found numerous real problems by doing so.
birkenfeld
commented
2 years ago
The current FFI bindings in
zmq-sys/src/ffi.rslook like they have been generated on a x86_64 machine almost three years ago. This is creating two kinds of problems:For example, the bindings assume 64-bit pointer widths, which is not correct on 32-bit x86 (and 32-bit ARM). The proper way to handle this would be to re-generate the bindings at build time, by using the bindgen library interface in the build script.
This would also solve issue https://github.com/erickt/rust-zmq/pull/329 properly (not by providing different tests on different architectures, but by actually generating the bindings and tests on the target architecture itself).
If the need to have the zmq headers available at build time is not something desirable, then the functionality for regenerating the bindings could be behind an off-by-default feature, so at least people who need to regenerate the bindings can do so.
Two of the most prominent crates that use bindgen at build time handle this very flexibly:
For example, in all packages in Fedora Linux for Rust crates that provide bindings for C libraries, we need to turn on regenerating bindings at build time, since we provide binaries for various architectures (including 64-bit and 32-bit targets of x86 and ARM, and others), and we have found numerous real problems by doing so.