How to handle (native) debug info?

[omajid]

In the context of packaging for various Linux distributions, the topic of (native) debuginfo comes up.

Here is what many linux distributions do:

1. Build a package with full debuginfo (-g with gcc/clang, RelWithDebInfo for cmake)
2. Run a separate tool to find all debuginfo, strip it and move it to a separate package (-debuginfo for Fedora/RHEL/CentOS, -dbgsym for Debian/Ubuntu).

Now if users want to just run .NET Core, they install dotnet. If they want to use the debug symbols, they need to install dotnet-debuginfo or dotnet-dbgsym (or the variant used by the distro).

Neither source-build nor the current official build accounts for this. These builds just strip out everything that leaves the package build process nothing to work with. For example, see https://github.com/dotnet/core-setup/issues/1607

I would like to "fix" this in source-build. Should I just remove the various invocations to strip debug info? Is there a need to make this conditional depending on the current platform? Or even build type?

[omajid]

Here is what an unconditional fix looks like for coreclr: https://gist.github.com/omajid/149e7df053fcaced9a717dee8a67f4f8

[dagood]

I'm surprised we're stripping symbols in source-build in the first place--packaging for distros is a big reason that flag exists rather than it being hard-coded one way or the other in the repo. Your patch LGTM.

@karajas, was that added intentionally in 4b935bc#diff-704fa01630c38f6175a0a426554e9825R5?

[karajas]

I believe at the time, we weren't sure how to handle core-setup symbols. If this is something that the official builds do, I think we should duplicate the same behavior.

[dagood]

Official builds are targeting Microsoft-style symbol servers, which is an area that source-build and the official build need to differ in the short term, IMO.

The work to have the official builds strip symbols after the builds are all done seems large to me--similar to the work to move signing to a post-step.

[omajid]

We could also introduce another RepoAPI parameter to control whether or not to strip binaries at build time. I dont know which is easier.

[dagood]

Yeah, all we need is to decide on name (should clarify it by adding native somewhere), make both repos use it, and then we're got a Repo API. 😄

However, I think as far as source-build's concerned, it will never be used. Worth standardizing if we plan on using it for a long time for Microsoft product builds, but otherwise (e.g. if we move stripping to the end) maybe not.

[omajid]

Okay, then I will keep things unconditional for now.

Btw, I looked into all native objects built as part of source-build and only corefx needs additional fixes. Basically a port of dotnet/coreclr#3445 from coreclr to corefx.

[dleeapho]

/cc @mikeharder in case asp.net core needs similar changes.

[mikeharder]

/cc @natemcmaster

[natemcmaster]

At the moment, the only native library aspnetcore builds is libuv. See https://github.com/aspnet/libuv-build. cc @moozzyk

[moozzyk]

The libuv build includes full debugging info for Linux builds. The size of the output is ~460 KB.