The part of the command that seems to break things is -fplugin=annobin -fplugin-arg-annobin-no-active-checks. I configure this in CMakeLists.txt to override the annobin which is enabled added from $CFLAGS when I also enable -fsanitize=address.

(In reply to Jiri Danek from comment #1)
Hi Jiri,

> The part of the command that seems to break things is -fplugin=annobin
> -fplugin-arg-annobin-no-active-checks. I configure this in CMakeLists.txt to
> override the annobin which is enabled added from $CFLAGS when I also enable
> -fsanitize=address.

As a guess, off the top of my head, what is happening here is that the annobin plugin is being run twice.  Since the second plugin generates the same symbol names as the first, the assembler then generates those error messages.  

If you try removing the "-fplugin=annobin" from CMakeLists.txt, but leave in the "-fplugin-arg-annobin-no-active-checks" then that might solve the problem.

As an alternative, you might try adding "-fplugin-arg-annobin-rename" to the set of annobin options in CMakeLists.txt.  This option tells the annobin plugin to rename the symbols it creates, in the hopes of avoiding conflicts like the one that you have encountered.  It is not really recommended as you will still have two plugins operating and so now have twice the number of annobin symbols, and annobin notes, in your binaries.  Its real use if for when the annobin plugin is being built and tested by a version of gcc where the annobin plugin is also active.

Please let me know if either of these suggestions work.  If not, then I will investigate further.

Cheers
  Nick

I think you are right as to the cause. The `-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1` expands to

    $ cat /usr/lib/rpm/redhat/redhat-annobin-cc1
    *cc1_options:
    + %{!-fno-use-annobin:%{!iplugindir*:%:find-plugindir()} -fplugin=gcc-annobin}

That is, my commandline ends up being something like

    gcc [...] -fplugin=gcc-annobin -fplugin=annobin -fplugin-arg-annobin-no-active-checks

and having both gcc-annobin and annobin enabled causes the error with already defined symbols.

Why does annobin and gcc-annobin both exist?

> If you try removing the "-fplugin=annobin" from CMakeLists.txt, but leave in the "-fplugin-arg-annobin-no-active-checks" then that might solve the problem.

This does not work, the "first" annobin is called `gcc-annobin`, so the option for it should be something like `-fplugin-arg-gcc-annobin-no-active-checks`, which does fail also, differently

    $ gcc -c main.c -fplugin=gcc-annobin -fplugin-arg-annobin-no-active-checks
    cc1: error: plugin annobin should be specified before ‘-fplugin-arg-annobin-no-active-checks’ in the command li

    $ gcc -c main.c -fplugin=gcc-annobin -fplugin-arg-gcc-annobin-no-active-checks
    cc1: error: plugin gcc should be specified before ‘-fplugin-arg-gcc-annobin-no-active-checks’ in the command line

How do I talk to gcc-annobin using the "-fplugin-arg-" option (when plugin name contains a dash)?

> you might try adding "-fplugin-arg-annobin-rename" to the set of annobin options

This works, but as you've said, it is not an ideal solution.

Currently, as a workaround, we decided to completely disable annobin, by getting CFLAGS with "--undefine _annotated_build", like this

    BUILD_FLAGS="$(rpmbuild --undefine _annotated_build --eval '%set_build_flags')"
    eval "${BUILD_FLAGS}"

(The original idea of using RPM flags there is to have RPM-like builds.)

(from https://github.com/skupperproject/skupper-router/pull/912)

(In reply to Jiri Danek from comment #3)
Hi Jiri,
 
> That is, my commandline ends up being something like
> 
>     gcc [...] -fplugin=gcc-annobin -fplugin=annobin
> -fplugin-arg-annobin-no-active-checks

Right.  Oh boy.

Do you really need to the "...-no-active-checks" option for annobin ?

I am guessing that this is because the plugin is complaining about -D_FORTIFY_SOURCE=2 not being used.  Although since it is definitely there on the command line, the plugin should not complain.

If you do not need that option then you could omit both annobin options from your CMakeLists.txt file. 

  
> Why does annobin and gcc-annobin both exist?

Ah - this is a long and sad tale.  The short version is that the annobin plugin for gcc is very sensitive to changes in the gcc sources.  Even minor changes to gcc can cause the plugin to start generating bogus notes, which then get flagged by annocheck as build failures.  In order to work around this problem we now build two versions of the plugin.  One whenever the annobin package is updated and one whenever the gcc package is updated.  Then there is special code in the redhat-rpm-config package which ensures that the correct plugin is chosen whenever gcc runs.

The gcc-built version of the plugin ensures that there is always a plugin that exactly matches the version of gcc installed.  The annobin-built version of the plugin allows new features and bug fixes to be added to the plugin without the need to rebuild all of gcc.



>     $ gcc -c main.c -fplugin=gcc-annobin
> -fplugin-arg-gcc-annobin-no-active-checks
>     cc1: error: plugin gcc should be specified before
> ‘-fplugin-arg-gcc-annobin-no-active-checks’ in the command line

Darn - that is something that we had not anticipated.

Calling the plugin gcc-annobin instead of say gcc_annobin was obviously a mistake.
Hmmm.  Actually having different names for the plugin is a mistake, since there is
no way for someone constructing a command line to know which plugin is going to be
selected.  We really should have called the plugins something else and then created
a symbolic link called "annobin" which would have meant that command lines could be
constructed properly.
 

I think that fixing this issue is going to get messy...


 
> Currently, as a workaround, we decided to completely disable annobin, by
> getting CFLAGS with "--undefine _annotated_build", like this
> 
>     BUILD_FLAGS="$(rpmbuild --undefine _annotated_build --eval
> '%set_build_flags')"
>     eval "${BUILD_FLAGS}"
> 
> (The original idea of using RPM flags there is to have RPM-like builds.)

Ok, that will work, but I agree that it is not ideal.  If you can live without the -fplugin-arg-annobin-no-active-checks then eliminating that and the -fplugin=annobin from the CMakeLists.txt file is a better workaround.


Cheers
  Nick

Hi Nick, thanks a lot for looking into this!

> -fplugin-arg-annobin-no-active-checks

This is there so that annobin does not freak out when we build with -fsanitize=. (The image contains regular binary, asanised binary, and tsanized binary; for testing.) It seemed the easiest solution at the time.

I am fairly happy with the workaround for now, and regarding this BZ, unless anything else breaks, I'm just going to just wait and see.

Cheers,
Jiri

Fixed in annobin-11.12-1.el8

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (annobin bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2023:6909