Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1541027

Summary: binutils: Does not use Fedora build flags
Product: [Fedora] Fedora Reporter: Florian Weimer <fweimer>
Component: binutilsAssignee: Nick Clifton <nickc>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: aoliva, dvlasenk, jakub, nickc
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: binutils-2.29.1-19.fc28 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-02-12 10:58:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1539083    

Description Florian Weimer 2018-02-01 14:49:50 UTC
binutils-2.29.1-15.fc28 was not built with the build flags specified in redhat-rpm-config.

Is there any reason for doing this?  binutils does not build any libraries for external users, so I expect it be to considerably less special than glibc and gcc in this regard.

Comment 1 Nick Clifton 2018-02-01 15:12:26 UTC
(In reply to Florian Weimer from comment #0)

> Is there any reason for doing this?

Nope.  It is just "how it has always been done"(tm).  I will investigate and try to fix.

Comment 2 Florian Weimer 2018-02-01 17:22:16 UTC
In binutils-2.29.1-16, you only injected CFLAGS, but did not set LDFLAGS.  The redhat-rpm-config default is available in the $RPM_LD_FLAGS shell variable within the %build section of the RPM spec file.

Comment 3 Nick Clifton 2018-02-01 17:24:10 UTC
Hi Florian,

  Please could you look at: binutils-2.29.1-16.fc28

  Built here: https://koji.fedoraproject.org/koji/taskinfo?taskID=24624810

  And let me know if this is what you were looking for.

Cheers
  Nick

Comment 4 Florian Weimer 2018-02-08 14:47:50 UTC
Nick, please see comment 2.  LDFLAGS appear to be missing still.

Comment 5 Nick Clifton 2018-02-08 17:27:43 UTC
Hi Florian,

  Sorry, I missed that.  Please see:  binutils-2.29.1-18.fc28 
  from build:

    https://koji.fedoraproject.org/koji/taskinfo?taskID=24840215

  This should be inject the linker flags correctly.

Cheers
  Nick

Comment 6 Florian Weimer 2018-02-09 16:17:46 UTC
Nick, I still do not see any annobin notes.  Is this intentional?

Comment 7 Nick Clifton 2018-02-12 10:27:48 UTC
Hi Florian,

  *sigh*  It was not intentional, but it was surprising.  It was all down
  to this *comment* in the binutils.spec file:

    # Only uncomment this next option if there is a problem building
    # the binutils and the compiler complains about the presence of
    # plugins.  The plugin should be harmless, but the compiler always
    # blames it first...
    # %undefine _annotated_build

  It seems that having "%undefine _annotated_build" in your spec file,
  even in comment form, is enough to disable annotations.  So I have
  removed the comment, rebuilt the binutils, and this time 
  "-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1" is showing up in the
  build logs.

  So please try: https://koji.fedoraproject.org/koji/taskinfo?taskID=24963268

Cheers
  Nick

Comment 8 Florian Weimer 2018-02-12 10:58:04 UTC
Thanks, binutils-2.29.1-19.fc28 confirmed as fixed.

Comment 9 Igor Gnatenko 2018-02-12 11:09:52 UTC
RPM always expands macro, be that in comment or not. You should use % to escape macros.. Like %%undefine __annotated_build.

Comment 10 Nick Clifton 2018-02-12 12:32:43 UTC
(In reply to Igor Gnatenko from comment #9)

> You should use % to escape macros.. Like %%undefine __annotated_build.

Thanks for the tip.  I think what got me though was not that the macro
was being expanded inside the comment, but that it was then being 
interpreted as well.  I guess that this is another case where I need to
pay attention to the warnings generated by "fedpkg lint".