Hide Forgot
rpm currently discards the debugging information in static libraries. As a result, statically linked programs lack debugging information for all system libraries. Except for select packages which copy .a files around, there is no way to recover the missing debugging information, leading to poor developer experience. I suggest we simply stop stripping static libraries. Relevant thread on the devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OFNQT4QPQB4TRHAD4FQTOHXBMORXJWQV/ I'll write up a proposal for a System-Wide Change.
I must say I strongly don't like this proposal. Unstripped static libraries are huge, we are in GCC intentionally not optimizing e.g. debug info for size of debug info with relocation, only for size of debug info after linking. And generally the debug info is not really very useful without the corresponding *-debuginfo packages installed. So I think it is better to have the non-stripped variants of static libraries in the *-debuginfo packages. After all, static linking is generally not recommended in Fedora, so for the rare case when one needs it it is possible to just tweak gcc command line to point it to the *-debuginfo variants.
For cases like Rust, static linking is the only sane choice, as there's no stable ABI to use for shared libraries. But since rpm strips all of Rust's rlibs, which are just ar archives, you miss a lot of debuginfo for standard library code. (The exception is generic code, which is only kept as metadata in the rlibs, thus that debuginfo is generated later when it's actually monomorphized.) However, I've heard rumors that Rust might start writing MIR in its rlibs instead of actual object code, in which case it will no longer be relevant to rpm here.
(In reply to Jakub Jelinek from comment #1) > I must say I strongly don't like this proposal. Unstripped static libraries > are huge, we are in GCC intentionally not optimizing e.g. debug info for > size of debug info with relocation, only for size of debug info after > linking. And generally the debug info is not really very useful without the > corresponding *-debuginfo packages installed. > So I think it is better to have the non-stripped variants of static > libraries in the *-debuginfo packages. I'll check with a mirror administrator, but I suspect -debuginfo packages are far more often installed than -static packages or even -devel packages. So please clarify what do you want to minimize: -devel packages, -static packages (if they exist), or -debuginfo packages? Or mirror size? > After all, static linking is generally not recommended in Fedora, so for the > rare case when one needs it it is possible to just tweak gcc command line to > point it to the *-debuginfo variants. Then we really should put the unstripped static archives into a directory which is not full of corrupted ELF files, otherwise we will just confuse users and have to deal with bug reports related to ld choking on separated debuginfo files. But I really don't think this is necessary, but I'll wait for the mirror statistics to provide some additional insight.
Jakub was right: It benefits most users if we move the unstripped static libraries to -debuginfo packages. For example, glibc, gmp, and llvm all have -static and -debuginfo packages, and on the mirror I had checked, -static had very few downloads (llvm-static just one), but at least there were some. For -debuginfo, there were none. It's not an artifact of mirror selection (but it could be related to how dnf handles -debuginfo package updates). This phenomenon is also visible in the public mirror statistics: https://admin.fedoraproject.org/mirrormanager/statistics/2016-11/repositories The -debug repositories are only consulted very rarely. This does not match my own usage at all, which is why I'm so surprised. Unfortunately, there is another problem with code in -debuginfo packages: Those packages cannot depend on the -devel headers, so you can easily install a static library which is incompatible with the headers you compile against, leading to difficult-to-diagnose bugs. How can we solve this? We probably need a separate subpackage to address this.
FESCo approved the Change today, but it sounds like you still have some open questions in comment #4. Do you know how you're going to approach this?
Based on the download statistics mentioned in comment #4, maybe we should do this: · Put the unstripped .a files into /usr/lib/static-debug and /usr/lib64/static-debug. (I think we should not reuse /usr/lib/debug paths because the directory would contain corrupt .so files as well, possibly confusing the linker.) · Install those files into the -debuginfo packages. · Rewrite the archives to reference the usual source paths. Then developers can install the -debuginfo packages and link with -L/usr/lib64/static-debug to access the unstripped libraries. (If we had -debuginfo-static packages, there should be an exact versioned dependency on the corresponding -devel package for the headers, but we can't put this into the -debuginfo package because it would interfere with parallel installation of multiple -debuginfo packages.) We probably need to move this to Fedora 27.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
I don't really know what the best solution is. Maybe we should look at a solution that uses GNU Debug Fission or DWARF5 split DWARF where most of of the non-relocationable DWARF structures are put in a separate .dwo file. Then you could keep the skeleton units in the (unstripped) static library. And package up the .dwo units into a .dwp file that goes into the debuginfo. Those skeleton units contain an ID of the .dwo units. We would then need to create some mapping that ties together the debuginfo package containing the skeleton units to the debuginfo package containing the .dwp file?
This doesn't seem to be going anywhere anytime soon, closing as deferred. Feel free to reopen if it these plans become reactivated.