-
Notifications
You must be signed in to change notification settings - Fork 1.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
Update Rust to 1.48 #6932
Update Rust to 1.48 #6932
Conversation
I can reproduce 64-bit Ouch:
|
Hope this build failing would be fixed. |
I believe I've got the fix (still testing it to be sure). @lazka I believe that would explain some of those cases:
|
So we should pass |
@lazka that would be complicated since executables and DLLs use different base addresses. |
Yes! I was considering sending another patch for binutils to allow selecting whether the default bases should be "high" or "low" via command line option. But I am not sold on that being a good idea. It would make hacking around buggy programs a lot easier though. Thoughts? |
It would definitely help with the transition. |
msys2#6932 and msys2#6907 show packages have issues with the new default base addresses, so add an option to change back to the old defaults during the transition.
I made a patch and am testing it now (simple tests worked as intended, going to attempt building GCC with it). I don't know if a 'transitional' option warrants upstreaming though. |
New binutils with |
I think using rust-lang/rust#72049 instead of |
a real upstream fix/backport is obviously better |
4faa8c9
to
7acf419
Compare
I have no idea why CI fails on x86_64 build, lets try again. |
b5f0661
to
2b0d14f
Compare
Not sure if relevant, but it finds the wrong Python: |
Blocked on #7116 |
CI now appears to be failing due to path length but it's kinda hard to tell. |
Or command line length, by the look of that ar command... I copy/pasted it and saw 36618 characters there! |
I think it should have used response file but yeah sounds plausible. |
Hi, What's holding up the rust upgrade ? A hard to solve technical problem or just lack of time from the maintainers ? |
Local build succeeds every time for me. |
Looking at the build log it seems the failed ar command originates from compiling libgit2-sys for cargo. I haven't heard yet of command line length being an issue when compiling any kind of software, but path length could certainly be an issue (some of those paths get pretty close to the Windows MAX_PATH length, and i686 config might just fall under that limit), though I'd be curious why this wasn't an issue with earlier package releases. In any case, 1.48 was released yesterday, so it might be worth trying a new ci build with that. |
IIRC I have inspected the longest paths and they were under the limit. Command line limit is definitely a thing on Windows but it depends on how you run the executable so I won't even try to guess what is the limit in this case. |
I have no idea why it fails with |
It means the release was signed with an ancient gnupg which doesn't include the full key ID in the signature, so auto key retrieval doesn't work. You can remove the signature to avoid it. |
Looks like the same issue. I did some searching online and found this -> rust-lang/cc-rs#496 To add some more context: The build.rs of libgit2-sys issues a cc::Build compile call which fails with the aforementioned error message, hopefully the problem will be fixed with that PR. |
nice :) should I merge? |
I have made basic tests with x86_64 before pushing and it worked so I guess it's good to go. |
thanks, I also built librsvg with it and all looks good. |
Just wait and watch. |
Closes #6758