-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
1.30.0 fails to build for target powerpc-unknown-netbsd #55465
Comments
Oh, btw, the cross-build of rust 1.30.0 from NetBSD/amd64 to NetBSD/earmv7hf fails the same way, and NetBSD/earmv7hf also has |
Upstream changes: Language * Procedural macros are now available. These kinds of macros allow for more powerful code generation. There is a new chapter available in the Rust Programming Language book that goes further in depth. * You can now use keywords as identifiers using the raw identifiers syntax (r#), e.g. let r#for = true; * Using anonymous parameters in traits is now deprecated with a warning and will be a hard error in the 2018 edition. * You can now use crate in paths. This allows you to refer to the crate root in the path, e.g. use crate::foo; refers to foo in src/lib.rs. * Using a external crate no longer requires being prefixed with ::. Previously, using a external crate in a module without a use statement required let json = ::serde_json::from_str(foo); but can now be written as let json = serde_json::from_str(foo);. * You can now apply the #[used] attribute to static items to prevent the compiler from optimising them away, even if they appear to be unused, e.g. #[used] static FOO: u32 = 1; * You can now import and reexport macros from other crates with the use syntax. Macros exported with #[macro_export] are now placed into the root module of the crate. If your macro relies on calling other local macros, it is recommended to export with the #[macro_export(local_inner_macros)] attribute so users won't have to import those macros. * You can now catch visibility keywords (e.g. pub, pub(crate)) in macros using the vis specifier. * Non-macro attributes now allow all forms of literals, not just strings. Previously, you would write #[attr("true")], and you can now write #[attr(true)]. * You can now specify a function to handle a panic in the Rust runtime with the #[panic_handler] attribute. Compiler * Added the riscv32imc-unknown-none-elf target. * Added the aarch64-unknown-netbsd target Libraries * ManuallyDrop now allows the inner type to be unsized. Stabilized APIs * Ipv4Addr::BROADCAST * Ipv4Addr::LOCALHOST * Ipv4Addr::UNSPECIFIED * Ipv6Addr::LOCALHOST * Ipv6Addr::UNSPECIFIED * Iterator::find_map * The following methods are replacement methods for trim_left, trim_right, trim_left_matches, and trim_right_matches, which will be deprecated in 1.33.0: * str::trim_end_matches * str::trim_end * str::trim_start_matches * str::trim_start Cargo * cargo run doesn't require specifying a package in workspaces. * cargo doc now supports --message-format=json. This is equivalent to calling rustdoc --error-format=json. * Cargo will now provide a progress bar for builds. Misc * rustdoc allows you to specify what edition to treat your code as with the --edition option. * rustdoc now has the --color (specify whether to output color) and --error-format (specify error format, e.g. json) options. * We now distribute a rust-gdbgui script that invokes gdbgui with Rust debug symbols. * Attributes from Rust tools such as rustfmt or clippy are now available, e.g. #[rustfmt::skip] will skip formatting the next item. Pkgsrc changest: * Explicitly list bootstrap kit version number for each kit we carry, so that one entry's version doesn't "bleed into" following kits. * Tweak for handling "earmv7hf" CPU type for NetBSD in the bootstrap.py script * Add two patches from Debian for sparc64; rust would generate code generating unaligned accesses, causing SIGBUS on sparc64 * Update most of the bootstrap kits to version 1.29.2; need minimum 1.29.0 to build 1.30.0. * Rust regrettably doesn't build for powerpc or earmv7hf in this version, most probably due to "char" being "unsigned char" on these platforms. Ref. rust-lang/rust#55465
https://pastebin.com/UXUeEHdJ contains a more complete build error log, for 1 month forward. |
T-compiler triage. Tagged this stable-to-stable regression with T-compiler. It needs a P-priority tag. I don't think powerpc-*-netbsd is a Tier 1 platform ... I don't know whether that means this should be considered P-medium ... it would probably be a good idea to at least double-check what happened here. (It seems like it should in theory be relatively easy to make a standalone test for this and then bisect to what nightly injected it...) |
Note that this problem also appears when (cross-)building for NetBSD/earmv7hf. |
I've been looking around, and have found the file The question is therefore now: where does |
The commit for fixing the signedness is in rust-lang/libc#1057
edit: I assume it’s to provide a local copy of any crates.io deps when it’s shipped. Something may be still using an outdated libc. Forwarding to others who would know what stage the vendor folder is included. edit 2: When the source tarball is produced, a builder on CI populates the vendor directory using |
Yep, I know. It's a bit frustrating having to re-discover old and already-solved bugs. I'm trying to copy over the contents from the "new" directory to the |
After grepping the source tarball for libc deps, src/bootstrap/Cargo.toml
43:libc = "0.2"
src/librustc_codegen_ssa/Cargo.toml
19:libc = "0.2.43"
vendor/wait-timeout/Cargo.toml
21:libc = "0.2"
vendor/termion/Cargo.toml
13:libc = "0.2.8"
vendor/commoncrypto-sys/Cargo.toml
15:libc = "0.2"
src/tools/compiletest/Cargo.toml
20:libc = "0.2"
src/tools/cargo/Cargo.toml
41:libc = "0.2"
src/stdsimd/crates/stdsimd/Cargo.toml
23:libc = "0.2"
src/librustc_codegen_ssa/Cargo.toml
19:libc = "0.2.43" libc
It would be better if
|
Yeah that's better. |
Sounds good. |
@memoryleak47 Just change |
Ah, thanks! It needed to be set exactly to Also, I did a lackluster grep earlier as there are more places that are not updated (e.g. rls and rustfmt have Is there a preferred way for updating git submodules? |
I'm new to this area, but ... if I understand correctly, version
I agree, that would be best. However, I'm just a poor sod of a packager, so work off the released So for me the alternative is probably to wait for the next release, |
@memoryruins I don't know about liblibc, but what I usually do is
It's because I think the problem is (Wait, how is |
Really?!? Well, the contents of |
@he32 The submodule doesn't have to be a version released on |
@eddyb thanks again for the tips! and yea, |
Ah. Makes it a bit more difficult to identify what you actually have, especially from the
I'm guessing that won't happen short-term... Anyway, thanks both of you for being patient and for working to narrow down this problem; I believe you now have enough info that this will be sorted out eventually. |
@he32 You can look at https://github.com/rust-lang/rust/tree/1.30.1/ - |
after 21 days I still don't know what P-label to assign here. Nominating for discussion at T-compiler meeting. (based on the very recent discussion, I am personally inclined to tag as P-high. If we don't get to it in today's meeting, that is probably what priority I will select.) |
discussed at T-compiler meeting. tagging as P-high and assigning to self to take point on working out what's gone on here. |
Okay, so I reviewed the discussion in this ticket. There are a couple different issues: Background: The libc version specified by librustc_codegen_ssa/Cargo.toml says
So, some crates in the distribution are definitely using libc It would almost certainly simplify @he32's life if we forced a version upgrade of our libc. One way to do this would simply be to replace
I suspect that while @eddyb's suggestion is the right long term solution, it also sounds a little bit more contentious (and certainly a bit more effort). So, here is a plan for addressing this:
The main reason I want to break things down this way is that steps 2 and 3 are internal maintenance/process issues. They are not bugs in the same way that this issue (#55465) is. |
So, some crates in the distribution are definitely using libc
`0.2.43`, which precedes the fix from rust-lang/libc#1057.
@he32 has been working around this by manually doctoring the
tarball.
Unsuccessfully, I might add. I have the diff for the libc source
(that's "easy" once we figured out that was the issue), but I
have been unable to figure out how to recompute the checksum for
the package as a whole, and my question how that's done has gone
unanswered. :(
So I'm for now stuck waiting for a fix for this bug and a new
full release incorporating that fix.
|
Q for @eddyb: when you said "Ideally we'd stop using submodules" ... did you mean to say "ideally we'd stop using a crates.io hosted crate?" Until I carefully re-read your comments, I had thought you were pushing for us to stop using a crates.io hosted crate, and instead point at a But my usual interpretation of the word "submodule" is that it means specifically a git submodule... |
@pnkfelix I definitely only meant |
…rsion, r=alexcrichton Update libc version required by rustc This is meant to be an easy-to-backport fix for rust-lang#55465
…rsion, r=alexcrichton Update libc version required by rustc This is meant to be an easy-to-backport fix for rust-lang#55465
…rsion, r=alexcrichton Update libc version required by rustc This is meant to be an easy-to-backport fix for rust-lang#55465
This will be fixed in Rust 1.31.1, scheduled to be released on Thursday 20th. |
This will be fixed in Rust 1.31.1, scheduled to be released on Thursday 20th.
Exellent, thanks!
|
T-compiler triage: I'll leave this open until the issue filer (he32) can confirm its fixed. |
T-compiler triage: I'll leave this open until the issue filer
(he32) can confirm its fixed.
I can confirm that this particular problem is fixed as of 1.31.1;
I've managed to complete a cross-build for 32-bit powerpc (after
working around another problem, which I'll open a separate issue
for).
|
I've cross-built and built natively rust 1.29.2 for (among others) powerpc-unknown-netbsd, and this appears to work fine. I'm now trying to upgrade to rust 1.30.0, and have managed to build it natively (on amd64 / x86_64) and cross-built for sparc64. However, the cross-build for the powerpc target fails with rust type mismatch compile errors, such as this:
Another example is:
Now, what separates the NetBSD/powerpc target from amd64 and sparc64 is that on NetBSD/powerpc, the
char
type isunsigned char
, whereas on the other two, it issigned char
.Has rust between 1.29.2 and 1.30.0 introduced code which makes assumptions about the signedness of the C type "char"? I've tried diff'ing the various openssl dirs between the two versions, but have unfortunately not found the problem.
The text was updated successfully, but these errors were encountered: