taiki-e
Add ability to retain debuginfo before stripping binaries
Thanks for the PR!
How do you plan to distribute the .debug file? Currently it is not included in the archive. (Here is code to include binary to archive.)
Also, is there any reason to prefer the objcopy command over the cargo profile option? I don't think that would work well with cross-compilation. (like https://github.com/taiki-e/upload-rust-binary-action/issues/8)
How do you plan to distribute the .debug file? Currently it is not included in the archive. (Here is code to include binary to archive.)
Right, I was thinking people could use the include functionality if they wanted them in the release tarball. My use case is actually a little different though, I want to build the binary, extract debuginfos, strip the binary, publish the binary as usual, and then publish the debuginfos separately on a debuginfod server.
Also, is there any reason to prefer the objcopy command over the cargo profile option? I don't think that would work well with cross-compilation. (like https://github.com/taiki-e/upload-rust-binary-action/issues/8)
Great question! The issue with the cargo profile option is that it doesn't produce the same data. It produces DWARF packages, which are nowhere near as well supported by tooling as regular DWARF.
I've used objcopy on various platforms and architectures and have never had issues with not being able to use the same objcopy for other platform/architecture binaries, but do you have a suggestion for how I could test this to make extra sure? (For example how could I reproduce what was described in #8?)
Any progress on this PR? Being able to upload a separate debug info archive would be great.
Any progress on this PR? Being able to upload a separate debug info archive would be great.
If you use the cargo profile mentioned in #59 and one of the include or asset options, you should be able to use this functionally without the specific option.
The main issue with this PR is that it is implemented in a way other than the cargo profile. We know from experience that that fact causes issue. Also it may not work correctly if strip option in cargo profile is specified. And in that case, it means that this will no longer work by default on 1.77+ (https://github.com/rust-lang/cargo/pull/13257).