Debugging Information For Static Libraries
This change proposes to ship debugging information in static libraries.
rpm strips static libraries and discards the debugging information in them (that is, the debugging information is not copied into the -debuginfo packages). After that, there is no way to recover the debugging information, say if it is needed to analyze an issue in a statically linked application.
This change proposes to stop stripping static libraries. To improve debugging experience, it is desirable that the static libraries are still rewritten at RPM build time, to point the file references to the final location under
The technical side of this change is tracked in bug 1395280.
Benefit to Fedora
Developers who use statically linked applications will have more information at hand when debugging their applications. Often, it is useful to see what the library is doing even if the actual is in application code.
- Proposal owners:
rpmneeds to be changed to stop stripping static libraries. If possible, static libraries should still be rewritten so that the debugging information points to the source files under
/usr/src/debug, for optimum developer experience.
- Other developers: Some packages copy static libraries into places where
rpmcannot find them, so that they are not stripped. These changes are not strictly necessary, but can reduce RPM/installation size for developer packages.
- Release engineering: This change requires a mass rebuild to become fully effective.
- List of deliverables: No release blocking deliverables.
- Policies and guidelines: no changes proposed (change will be implemented through
- Trademark approval: N/A (not needed for this Change)
There will be no impact.
How To Test
The presence of additional debugging information does not affect application behavior.
The availability of debugging information in static library can be tested with
There will be no user-visible impact. Developers will be able to step into system library code when debugging statically linked applications.
rpm change should be made as soon as possible, well before the first mass rebuild.
- Contingency mechanism: Drop the change.
- Contingency deadline: Final mass rebuild.
- Blocks release? No.
- Blocks product? No.
No documentation updates are needed.
The release notes should mention that developers who do not want debugging information in statically linked applications should link with the
-s flag or run the
strip command after linking.