-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
c_char has changed on ARM in 1.6 #29867
Comments
Some other points:
|
Note that #29775 only changed It sucks. My solution has been to pin specific versions via hacking on Cargo.lock. I'm not sure that reverting back to the wrong type is the right course of action to take, though. |
Should library use types from |
That's a good question! I don't think it should matter as the types should in theory always be the same. |
I think they should, tbh. In theory they should be the same, but if you plan on using std methods, you should be using the types it exports, and not assuming some external crates.io crate matches up. For bonus points: make them quasi-newtypes so a cast between the two is required :P Also: All Android platforms (including x86) seem to be affected. |
Can we reorganize this somehow so that we use a single source of truth? Defining |
The libs team discussed this during triage yesterday and the conclusion was that we're unlikely to go back to the old incorrect definitions and otherwise we'll basically just do what we can to help mitigate this breakage. @bluss that's possible, yeah, although it wouldn't have fixed this problem because the "single source of truth" from before was wrong (both libstd and libc disagreed). |
I hope that updating all the things (servo/servo#8608) to libc 0.2 will fix the build errors related to this for Servo. |
@alexcrichton But the major fallout comes from incompatible types, not from the change per se? If all the crate including libc used |
Yeah that's true and it would help mitigate problems like this. There's a number of interesting issues around libc reexporting types from the standard library, however, so it's currently not done. |
@bluss but libc is the source of Maybe the libc crate should use a cfg feature for this? Set that feature to provide its own good |
Fix compilation on arm using stable rust 1.5
Even |
Android was changed in #29546 and Linux ARM was changed in #29775. Both are bug fixes as the definitions have been corrected, but this is causing breakage:
Can we help mitigate this breakage? Should we revert "the fix" for now?
Opening a tracking issue (and nominating it) to discuss this.
The text was updated successfully, but these errors were encountered: