Produce debuginfo/dbgpkg RPM and Debian packages #3781
Labels
area-Setup
backlog-cleanup-candidate
An inactive issue that has been marked for automated closure.
no-recent-activity
Milestone
Comments
omajid
added a commit
to omajid/dotnet-runtime
that referenced
this issue
Sep 30, 2020
When packaging .NET for Linux distributions, the package builders
generally use a different workflow for shipping symbols to users:
1. The package maintainer builds code with the debug flags (such as
`-g`) to generate full native debug info and symbols.
2. Nothing is stripped from build by the package maintainer.
3. The build system (`rpmbuild`, `debuild`) removes the debug
info (or debug symbols) from the code and creates separate
`-debuginfo` or `-debug` packages that contain just the debug
symbols.
4. These debug packages are then distributed along with the normal
packages using the normal Linux distribution mechanisms. This lets
users install the exact set of debug symbols matching their other
package.
To support this workflow in dotnet/runtime, we need to add optional
support for not stripping debug symbols. I used it has follows:
CFLAGS=-g CXXFLAGS=-g ./build.sh --keepnativesymbols true
After this build, the built binaries include all debug symbols.
I can then rely on the distro package build system to identify, strip,
package and ship the debug info/symbols separately.
See dotnet#3781 and
dotnet/source-build#267 for more details on
the background and motivation.
For some related fixes, see:
- dotnet/coreclr#3445
- dotnet/corefx#24979
jkotas
pushed a commit
that referenced
this issue
Oct 1, 2020
When packaging .NET for Linux distributions, the package builders
generally use a different workflow for shipping symbols to users:
1. The package maintainer builds code with the debug flags (such as
`-g`) to generate full native debug info and symbols.
2. Nothing is stripped from build by the package maintainer.
3. The build system (`rpmbuild`, `debuild`) removes the debug
info (or debug symbols) from the code and creates separate
`-debuginfo` or `-debug` packages that contain just the debug
symbols.
4. These debug packages are then distributed along with the normal
packages using the normal Linux distribution mechanisms. This lets
users install the exact set of debug symbols matching their other
package.
To support this workflow in dotnet/runtime, we need to add optional
support for not stripping debug symbols. I used it has follows:
CFLAGS=-g CXXFLAGS=-g ./build.sh --keepnativesymbols true
After this build, the built binaries include all debug symbols.
I can then rely on the distro package build system to identify, strip,
package and ship the debug info/symbols separately.
See #3781 and
dotnet/source-build#267 for more details on
the background and motivation.
For some related fixes, see:
- dotnet/coreclr#3445
- dotnet/corefx#24979
|
Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process. This process is part of our issue cleanup automation. |
dotnet-policy-service
bot
added
backlog-cleanup-candidate
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The Microsoft approach of storing symbols in a symbol server and downloading them based on file info is unusual for Linux development. We should provide debug packages that contain symbols and install them adjacent to the corresponding binary to fit in better with the ecosystem.
Both native and managed symbols should be included.
dbg/dbgsympackages: https://wiki.debian.org/DebugPackageIdeally this functionality can be included in shared tooling and apply to ASP.NET Core and the .NET Core SDK, but no such shared tooling currently exists. (Once it does, this issue may belong in dotnet/arcade.)
/cc @sdmaclea @dleeapho
The text was updated successfully, but these errors were encountered: