If the option would exist, then it would be %{!fno-use-annobin:...}, without the leading -, but one can't add new options this way.
When the plugin is loaded, one should be able to use plugin specific options, like -fplugin-arg-annobin-disable if the annobin plugin would implement this option.
Another option is a hack, like:
+ %{!D__NO_USE_ANNOBIN:%{!iplugindir*:%:find-plugindir()} -fplugin=annobin}
and use as the magic option to disable annobin not -fno-use-annobin, but -D__NO_USE_ANNOBIN.

Peter, would

%undefine _annotated_build

work for you?  Or do you need different compiler settings in a single package build?

Hi Guys,

> foo.o foo.c -fno-use-annobin
> cc1: error: unrecognized command line option ‘-fno-use-annobin’

Doh - I had forgotten about the fact that cc1 will check for unrecognised option.
It will also complain about -mno-use-annobin, so we could not use that option either.


> When the plugin is loaded, one should be able to use plugin specific
> options, like -fplugin-arg-annobin-disable if the annobin plugin would
> implement this option.

This option is implemented.


> Another option is a hack, like:
> + %{!D__NO_USE_ANNOBIN:%{!iplugindir*:%:find-plugindir()} -fplugin=annobin}
> and use as the magic option to disable annobin not -fno-use-annobin, but
> -D__NO_USE_ANNOBIN.

That should work, and at least it is better than the unworking -fno-use-annobin.
I think that the official way is to %undefine _annotated_build, as mentioned by Florian.

I am intrigued though - why would someone want to disable the plugin ?

(In reply to Florian Weimer from comment #2)
> Peter, would
> 
> %undefine _annotated_build
> 
> work for you?  Or do you need different compiler settings in a single
> package build?

I think it would, yes - I just didn't find it first, and since this looked half-implemented I figured it was worth filing a bug.

(In reply to Nick Clifton from comment #3)
> > When the plugin is loaded, one should be able to use plugin specific
> > options, like -fplugin-arg-annobin-disable if the annobin plugin would
> > implement this option.
> 
> This option is implemented.

Could it be documented better? :)

> > Another option is a hack, like:
> > + %{!D__NO_USE_ANNOBIN:%{!iplugindir*:%:find-plugindir()} -fplugin=annobin}
> > and use as the magic option to disable annobin not -fno-use-annobin, but
> > -D__NO_USE_ANNOBIN.
> 
> That should work, and at least it is better than the unworking
> -fno-use-annobin.
> I think that the official way is to %undefine _annotated_build, as mentioned
> by Florian.
> 
> I am intrigued though - why would someone want to disable the plugin ?

Right now it breaks grub.efi builds, but I haven't yet sufficiently diagnosed *how* to figure out if that's my bug or yours.

(In reply to Nick Clifton from comment #3)
> > When the plugin is loaded, one should be able to use plugin specific
> > options, like -fplugin-arg-annobin-disable if the annobin plugin would
> > implement this option.
> 
> This option is implemented.

However, it still causes an error if the plguin is not loaded.  So I'm not sure if we can use it to inhibit loading the plugin altogether when it is specified.

I documented the flag here:

https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/buildflags.md

Created attachment 1384904 [details]
Proposed patch

(In reply to Peter Jones from comment #4)

> > > When the plugin is loaded, one should be able to use plugin specific
> > > options, like -fplugin-arg-annobin-disable if the annobin plugin would
> > > implement this option.
> > 
> > This option is implemented.
> 
> Could it be documented better? :)

Fair point.  Where would you expect to find this documentation ?

I am attaching a proposed patch which would add documentation to the macros
file in the redhat-rpm-config package.  (And also remove the non-functional
-fno-use-annobin option).

I am not a maintainer for the redhat-rpm-config package however, so I do no
know if this is an acceptable way to solve the problem.

> > Could it be documented better? :)
> 
> Fair point.  Where would you expect to find this documentation ?

Well, the first place I went looking was "info gcc", which somewhat surprisingly doesn't include anything about annobin /at all/, including any disable options.  So basically looking at the most common place for gcc argument documentation, the only thing is the generic arguments "-fplugin=FILE  -fplugin-arg-NAME=ARG" without any text about disabling or any documentation of what any modules do at all.  This is where I would expect to find docs; am I looking at the wrong place?  Are plugins documented someplace else?

> I am attaching a proposed patch which would add documentation to the macros
> file in the redhat-rpm-config package.  (And also remove the non-functional
> -fno-use-annobin option).
> 
> I am not a maintainer for the redhat-rpm-config package however, so I do no
> know if this is an acceptable way to solve the problem.

It seems like a reasonable start to me, but... same :)

Hi Peter,

> > Fair point.  Where would you expect to find this documentation ?
> 
> Well, the first place I went looking was "info gcc", which somewhat
> surprisingly doesn't include anything about annobin /at all/,

Ah - you have hit on a personal bugbear of mine.  The gcc project does not want anything to do with specific plugins.  All they care about is providing the framework to allow plugins to work.  (And they are not very good about guaranteeing a stable plugin interface either).  I did try to get them to acknowledge that plugins are now a useful part of gcc and ought to have their own place in the project - including documentation, testsuites, integration into the build system and so on.  But they said "no". :-(

So it is up to the individual plugin to provide its own documentation.  And to put it somewhere that the user might be able to find it.  This is where the annobin plugin currently falls down - there is no documentation.  In theory the plugin is meant to be transparent, ie it should be invisible to the user and have no noticeable affect on their builds.  (Other than their binaries becoming slightly larger).  In practice of course that goal is not always achieved, so, yes, I do need to write some documentation.  One set of deathless prose coming up...

Cheers
  Nick

Hi Guys,

FYI: annobin-3.2-1.fc28 now has an info file describing the packge, including how to disable the plugin.

Cheers
  Nick

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

I am hitting the same problem.

I am trying to build OpenHPC packages on an annobin system. OpenHPC builds its own compiler and I am setting '%undefine _annotated_build'.

The problem is building python modules. The python module picks its compiler flag not from the RPM optflags but from /usr/lib64/python3.6/_sysconfigdata_m_linux_x86_64-linux-gnu.py (I think) and the undefine from above is ignored.

As I am building with my own compiler the plugin is not found and loaded and I cannot disable it:

export CFLAGS="-fplugin-arg-annobin-disable"

/opt/ohpc/pub/mpi/openmpi3-gnu8/3.1.2/bin/mpicc -pthread -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -fplugin-arg-annobin-disable -fPIC -I/usr/include/python3.6m -c _configtest.c -o _configtest.o
cc1: error: plugin annobin should be specified before -fplugin-arg-annobin-disable in the command line
cc1: fatal error: inaccessible plugin file /opt/ohpc/pub/compiler/gcc/8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/plugin/annobin.so expanded from short plugin name annobin: No such file or directory

As it is very common for HPC sites to build their own compiler this will probably hit most HPC users if compiling python modules.

Any ideas how to workaround or fix this? The problem seems to be that python hardcodes annobin usage into its CFLAGS, which normally is not a problem, but in a scenario like described above, it does not work.

Hi Adrian,

(In reply to Adrian Reber from comment #11)

> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic

> -D_GNU_SOURCE -fPIC -fwrapv -fplugin-arg-annobin-disable -fPIC

> cc1: error: plugin annobin should be specified before
> -fplugin-arg-annobin-disable in the command line

  This is actually a gcc bug.  It fails to expand the options in the 
  redhat-annobin-cc1 spec file before it attempts to handle the 
  -fplugin-arg-annobin-disable option.  But it is unlikely that gcc 
  will be fixed any time soon. :-(

  There is however a rather hackish workaround for this problem - load
  the plugin twice!  Ie change:
    
     CFLAGS="-fplugin-arg-annobin-disable"

   to:

     CFLAGS="-fplugin=annobin -fplugin-arg-annobin-disable"

  This should work.  The annobin plugin will be loaded twice,
  but it will also be disabled twice, so the end result is as if the
  plugin was never loaded at all.

Cheers
  Nick

Hi Nick,

thanks for the proposed workaround. Unfortunately, it does not work as my self compiled gcc only looks in its own search path for the annobin plugin:

cc1: fatal error: inaccessible plugin file /opt/ohpc/pub/compiler/gcc/8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/plugin/annobin.so expanded from short plugin name annobin: No such file or directory

So if python would not hardcode the use of annobin that would probably solve the problem here.

Hi Adrian,

(In reply to Adrian Reber from comment #13)
> Hi Nick,
> 
> thanks for the proposed workaround. Unfortunately, it does not work as my
> self compiled gcc only looks in its own search path for the annobin plugin:
> 
> cc1: fatal error: inaccessible plugin file
> /opt/ohpc/pub/compiler/gcc/8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/plugin/
> annobin.so expanded from short plugin name annobin: No such file or directory> 

You could add a plugin directory to the search path if you wished:

  cc1 -iplugindir=/usr/lib/gcc/x86_64-redhat-linux/8/plugin/ \
    -fplugin=annobin ....


> So if python would not hardcode the use of annobin that would probably solve
> the problem here.

I cannot help you here though. :-(  Perhaps you could work with the python people to find a way to solve the problem ?

Cheers
  Nick

> You could add a plugin directory to the search path if you wished:
> 
>   cc1 -iplugindir=/usr/lib/gcc/x86_64-redhat-linux/8/plugin/ \
>     -fplugin=annobin ....

Nice, that works. Does this extend the plugin search path or does it change the plugin search path. Just to better understand if now all plugins are taken from the system gcc plugin directory or from my gcc installation and from the system compiler.

> > So if python would not hardcode the use of annobin that would probably solve
> > the problem here.
> 
> I cannot help you here though. :-(  Perhaps you could work with the python
> people to find a way to solve the problem ?

Yes, I will definitely talk to them about this. Thanks for your help so far.

Hi Adiran,

> Nice, that works. Does this extend the plugin search path or does it change
> the plugin search path.

It replaces it.  (Which surprises me, I thought that it augmented the search path, but I checked the code just to be sure, and found out that it replaces the default search path, and multiple options do not accumulate, they just override previous entries).

Is this going to be a problem ?  Do you load other plugins ?

One thing I did not check was whether the -fplugin option is evaluated at its position on the command line, or later on.  So I do not know if:

  -iplugindir=/dir1 -fplugin=plug1 -iplugindir=/dir2 -fplugin=plug2

will load plug1 from dir1 or dir2 ...

Cheers
  Nick

Hello Nick,

> > Nice, that works. Does this extend the plugin search path or does it change
> > the plugin search path.
> 
> It replaces it.  (Which surprises me, I thought that it augmented the search
> path, but I checked the code just to be sure, and found out that it replaces
> the default search path, and multiple options do not accumulate, they just
> override previous entries).
> 
> Is this going to be a problem ?  Do you load other plugins ?

Thanks for looking into it. No, it is not a problem. I just wanted to know it, to make sure I will not be surprised (too much) by some unexpected behaviour due to missing or wrong plugins. Thanks for all your help so far. I will open a new BZ for the hard-coded python annobin usage to see what can be done to find a solution.

This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.