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 - binutils: Does not use Fedora build flags
Summary: binutils: Does not use Fedora build flags
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: Fedora28BuildFlags
TreeView+ depends on / blocked
 
Reported: 2018-02-01 14:49 UTC by Florian Weimer
Modified: 2018-02-12 12:32 UTC (History)
4 users (show)

Fixed In Version: binutils-2.29.1-19.fc28
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-02-12 10:58:04 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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".
Note You need to log in before you can comment on or make changes to this bug.