-
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
Package debug libstd with binaries #20630
Comments
There are some options: we could just provide separate debuginfo for the optimized std, but we could also provide an unoptimized std with debuginfo. |
I would personally be very worried about binary distribution size if we distribute yet another set of copies of the standard library, but the idea here sounds great! |
Still something we want to do. |
I'd very much like an optional package that bundles .pdb debug info for the exe and dll binaries in the nightlies. Sometimes I want to debug what rustc is doing or profile it, and I can't really do it unless I build rustc from source. |
Triage: no changes here. I wonder if we'll do this, or if we'll eventually get to "cargo aware std", where you can get your own debug build when building your project. |
Visiting for wg-debugging triage Some questions that we had while thinking about this:
It seems like a very open question about whether we would do this at all at this point, and if we did, I suspect it would need to be driven by an RFC. Especially since, from our point of view, it is hard for the members of wg-debugging to understand the scenario where someone "wants to debug std but not as part of working on std"; we imagine that the best way to debug libstd is to make your own local build of rust. (If the real motivation here is "it is too costly to do a local build", then I can understand that. but I want to make sure that is indeed the key motivation.) Anyway, as implied by the previous paragraph, I am currently thinking that we may want to close this issue, with the statement "If you want to propose this, please file an RFC." But I want to give other people the chance to weigh in, especially members of T-infra. |
Given the work on split-debuginfo, would it be possible to package the debuginfo in a separate file? That would avoid having to ship a second copy of the standard library. |
For debugging it's useful to have a debug build of std. Figuring out how to make the debugger actually locate the source in all scenarios could be complicated.
The text was updated successfully, but these errors were encountered: