-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable crate on 32-bit architectures #73
Comments
Thanks for the report! Do you have any pointer to how to emulate a 32bit target in a cargo test suite? Would love to figure out some way to troubleshoot locally and land some patches. Open to pull requests too if this looks easy to patch on your end. |
@dginev not really sure, but I guess by specifying |
@dginev I guess this is because you have generated bindings using bindgen just on your computer so things like https://github.com/KWARC/rust-libxml/blob/master/src/bindings.rs#L16-L20 just get hardcoded there, together with other things. Proper solution would be to use bindgen from build.rs to have it generated dynamically. |
That's a good tip! Sadly, I think I'll need to make a VM after all, since I also need the native |
Ah, having to run bindgen on every build would likely be a good solution. Seems like a lot of wasted work if you stick to the same platform, but definitely makes sense for the 32-bit case. Will take a look into that... |
@dginev well, it is not only about 32bit case, but also about libxml2 version (the bindings which are generated are derived for some specific libxml2 version, so let's say if I try to use those constants in my code, they will report wrong information). Oh yeah, we also have another beast - s390x which is BigEndian, that can also behave for some things differently :) Let me know once you have some patch which uses bindgen dynamically or some other fix and I can try it out. |
Started investigating and quickly ran into the full list of painpoints that has seemingly been discussed online before: It seems that the reasonable way out of the heavy bindgen dependency burden is to
So I'll likely have to get a VM with your setup, generate an alternative The good news is that libxml2 itself is a slow velocity project due to its maturity, so regenerating the bindings file on breakage is a reasonable tradeoff. Might be years until that is needed. My long-term hope for the crate is to bundle in a Rust-transpiled equivalent of libxml2 (in development by c2rust), and entirely escape the C dependency games. Will read more in that reddit thread, and let you know when I have the build mechanism. If you feel like running bindgen as specified in the PR #74 , and share the resulting file with me, that would speed me along nicely. |
@dginev any news here? This is blocking me from getting https://gitlab.com/news-flash/news_flash_gtk from being packaged. |
Maybe we need to remove unnecessary assert. I've generated bindings.rs on Manjaro, tested on Windows10, and found out that Similarly, we need to remove the pointer's size assert for 32-bit . |
As suggested by @simoin , I've dropped a few troublesome asserts in #78 , wouldn't call them "unnecessary", but definitely difficult to maintain for multiple architectures... I've done so only to the extent where the Appveyor CI can successfully pass tests on Windows, and just released a So, if anyone wants to revisit here and file a better PR than my half-hearted #76, they should feel welcome. |
I wonder, are the bindings themselves actually different between the different architectures, or is it just the tests (which hard-code architecture specific expected struct sizes and struct layout / field offsets)? If the bindings themselves are architecture-independent but the generated bindgen tests hard-code information that depends on the host system, then the easiest solution would probably be to just wrap the tests in |
full bindgen trace
Noticed that when runnning
cargo test
on i686 and armv7hl.The text was updated successfully, but these errors were encountered: