Bug 927608 - RPM is ignoring debug_package %{nil}
Summary: RPM is ignoring debug_package %{nil}
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gcc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 967258
TreeView+ depends on / blocked
 
Reported: 2013-03-26 10:26 UTC by Patrick Uiterwijk
Modified: 2021-09-27 19:03 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
GNU Compiler Collection 57194 0 P3 RESOLVED go binaries give "no debug info in ELF executable errno -1" 2021-01-26 13:46:17 UTC

Description Patrick Uiterwijk 2013-03-26 10:26:14 UTC
Description of problem:
Rpmbuild is ignoring the %define debug_package %{nil} statement.

Version-Release number of selected component (if applicable):
rpm

How reproducible:
Always, since some recent version (the same build did succeed a little while ago)

Steps to Reproduce:
1. Try to build a package that cannot produce debug information
  
Actual results:
no debug info in ELF executable errno -1

Expected results:
A correctly built package

Additional info:
I am aware that I should change it to %global, but that does not fix the problem.
An example build that displays this problem is: https://koji.fedoraproject.org/koji/taskinfo?taskID=5169239.
devtodo2 can not produce debug information, because gcc-go does not support this.

Comment 1 Panu Matilainen 2013-03-27 07:18:16 UTC
Disabling the debuginfo package from rpm is still working fine AFAICS, but that error comes from gcc (libbacktrace), not rpm. Reassigning.

Comment 2 Panu Matilainen 2013-03-27 07:19:09 UTC
Oh and FWIW, the package builds fine on F18 so this is probably something specific to gcc 4.8.x.

Comment 3 Allan 2013-05-01 14:24:05 UTC
FYI, I have had what is essentially the same issue reported in Arch Linux with gcc-4.8 (hence nothing to do with RPM) [1].

Summary:
gccgo -g foo.go -> GOOD
gccgo foo.go -> BAD
gccgo foo.go + strip -> BAD

[1] https://bugs.archlinux.org/task/35048

Comment 4 Christopher Meng 2013-08-08 08:51:40 UTC
Hitting same issue here.

-g is the solution but we should let gcc automatically "add" it.

Comment 5 Fedora End Of Life 2013-09-16 13:19:32 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

Comment 6 Jan Kratochvil 2015-01-20 18:54:17 UTC
(In reply to Christopher Meng from comment #4)
> -g is the solution but we should let gcc automatically "add" it.

This is not valid, gcc just historically does not default to -g.

This should be rather addressed in:
  https://fedoraproject.org/wiki/PackagingDrafts/Go
+
  Go Packaging Guidelines Draft
  https://fedorahosted.org/fpc/ticket/382
And currently Fedora seems to use golang instead of gccgo for whatever reason.

Suggesting to close this Bug.

Comment 7 Thomas Moschny 2015-02-04 15:11:01 UTC
(In reply to Jan Kratochvil from comment #6)
> (In reply to Christopher Meng from comment #4)
> > -g is the solution but we should let gcc automatically "add" it.
> 
> This is not valid, gcc just historically does not default to -g.
> 
> This should be rather addressed in:
>   https://fedoraproject.org/wiki/PackagingDrafts/Go
> +
>   Go Packaging Guidelines Draft
>   https://fedorahosted.org/fpc/ticket/382
> And currently Fedora seems to use golang instead of gccgo for whatever
> reason.
> 
> Suggesting to close this Bug.

Sorry, but I have to disagree.

From a user's pov, gccgo simply doesn't work as expected: one has to pass '-g' to it to actually produce working binaries.

This has nothing to do with the Go Packaging Guidelines or the question whether Fedora uses golang for compiling *other packages*.

Comment 8 Jakub Jelinek 2015-02-04 15:32:01 UTC
gcc-go-5.0.0-* gccgo defaults to -g1 if no -g is passed.
And, doesn't fail miserably at startup if debug info is missing, though some features like backtrace might not work properly.


Note You need to log in before you can comment on or make changes to this bug.