-D_FORTIFY_SOURCE defined but value is too low [-Werror]

[Daniel P. Berrangé]

I'm getting the strange error in $SUBJECT in an upstream CI job that
is targetting Fedora rawhide. I'm guessing it is something related to
the recent changes to set the  _FOTIFY_SOURCE value to 3 instead of
2, but not sure what. 

What I'm finding especially bizarre is that I can't reproduce it on
rawhide myself, despite using the exact same package versions and
base container.

I can't even figure out which particular component is emitting this
error message string. My only thought is that perhaps it could be
ccache related, since upstream CI has ccache enabled and the cache
is preserved across CI pipelines. That could explain why I can't
reproduce myself.

My app has a config.h file used by all sources that does

  #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__
  # define _FORTIFY_SOURCE 2
  #endif

but the -D_FORTIFY_SOURCE=3 set by RPM in CFLAGS on the gcc command
line ought to override this fine.

$ gcc -Ilibvirt-glib/libvirt-glib-1.0.so.0.4000.0.p -Ilibvirt-glib -I../libvirt-glib -I.
-I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 ...snip
many -Wxxx flags... -fexceptions -fasynchronous-unwind-tables -fipa-pure-const 
-fstack-protector-strong -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe  -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE
-Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -pthread
'-DLOCALEDIR="/usr/share/locale"'
'-DDATADIR="/usr/share"' -DLIBVIRT_GLIB_BUILD
-DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_48 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_48
-MD -MQ libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -MF
libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o.d -o
libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -c
../libvirt-glib/libvirt-glib-error.c
../libvirt-glib/libvirt-glib-error.c: error: -D_FORTIFY_SOURCE defined but value is too
low [-Werror]
cc1: all warnings being treated as errors

So does anyone know what this error message would be coming from, and more
importantly how to make it go away :-)

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Jonathan Wright]

Are you by chance running this inside of a rawhide docker container within
GH actions?  If so, I'm in the same boat and haven't figured out how to
force it back to "2", or why it's failing in the first place.

On Mon, Jan 16, 2023 at 12:05 PM Daniel P. Berrangé <berrange(a)redhat.com&gt;
wrote:

>  I'm getting the strange error in $SUBJECT in an upstream CI job
> that
>  is targetting Fedora rawhide. I'm guessing it is something related to
>  the recent changes to set the  _FOTIFY_SOURCE value to 3 instead of
>  2, but not sure what.
>
>  What I'm finding especially bizarre is that I can't reproduce it on
>  rawhide myself, despite using the exact same package versions and
>  base container.
>
>  I can't even figure out which particular component is emitting this
>  error message string. My only thought is that perhaps it could be
>  ccache related, since upstream CI has ccache enabled and the cache
>  is preserved across CI pipelines. That could explain why I can't
>  reproduce myself.
>
>  My app has a config.h file used by all sources that does
>
>    #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__
>    # define _FORTIFY_SOURCE 2
>    #endif
>
>  but the -D_FORTIFY_SOURCE=3 set by RPM in CFLAGS on the gcc command
>  line ought to override this fine.
>
>  $ gcc -Ilibvirt-glib/libvirt-glib-1.0.so.0.4000.0.p -Ilibvirt-glib
>  -I../libvirt-glib -I. -I.. -I/usr/include/glib-2.0
>  -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4
>  -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
>  -std=gnu99 ...snip many -Wxxx flags... -fexceptions
>  -fasynchronous-unwind-tables -fipa-pure-const  -fstack-protector-strong -O2
>  -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe
>  -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=3
>  -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
>  -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64
>  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection
>  -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC
>  -pthread '-DLOCALEDIR="/usr/share/locale"'
> '-DDATADIR="/usr/share"'
>  -DLIBVIRT_GLIB_BUILD -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_48
>  -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_48 -MD -MQ
>  libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -MF
>  libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o.d -o
>  libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -c
>  ../libvirt-glib/libvirt-glib-error.c
>  ../libvirt-glib/libvirt-glib-error.c: error: -D_FORTIFY_SOURCE defined but
>  value is too low [-Werror]
>  cc1: all warnings being treated as errors
>
>  So does anyone know what this error message would be coming from, and more
>  importantly how to make it go away :-)
>
>  With regards,
>  Daniel
>  --
>  |: https://berrange.com      -o-
>  https://www.flickr.com/photos/dberrange :|
>  |: https://libvirt.org         -o-
>  https://fstop138.berrange.com :|
>  |: https://entangle-photo.org    -o-
>  https://www.instagram.com/dberrange :|
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>  

-- 
Jonathan Wright
AlmaLinux Foundation
Mattermost: chat <https://chat.almalinux.org/almalinux/messages/@jonathan>

[Daniel P. Berrangé]

On Mon, Jan 16, 2023 at 12:06:59PM -0600, Jonathan Wright wrote:
>  Are you by chance running this inside of a rawhide docker container
> within
>  GH actions?  If so, I'm in the same boat and haven't figured out how to
>  force it back to "2", or why it's failing in the first place. 
No, I'm using GitLab CI, rather than GitHub.  Still docker, but I
fully control the container content, which usually means I can
100% reliably reproduce problems locally but not this time :-(


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Siddhesh Poyarekar]

On Mon, Jan 16, 2023 at 1:05 PM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote:
>  I'm getting the strange error in $SUBJECT in an upstream CI job that
>  is targetting Fedora rawhide. I'm guessing it is something related to
>  the recent changes to set the  _FOTIFY_SOURCE value to 3 instead of
>  2, but not sure what.
>
>  What I'm finding especially bizarre is that I can't reproduce it on
>  rawhide myself, despite using the exact same package versions and
>  base container.
>
>  I can't even figure out which particular component is emitting this
>  error message string. My only thought is that perhaps it could be
>  ccache related, since upstream CI has ccache enabled and the cache
>  is preserved across CI pipelines. That could explain why I can't
>  reproduce myself.
>
>  My app has a config.h file used by all sources that does
>
>    #if !defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__
>    # define _FORTIFY_SOURCE 2
>    #endif
>
>  but the -D_FORTIFY_SOURCE=3 set by RPM in CFLAGS on the gcc command
>  line ought to override this fine.
>
>  $ gcc -Ilibvirt-glib/libvirt-glib-1.0.so.0.4000.0.p -Ilibvirt-glib -I../libvirt-glib -I.
> -I.. -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/sysprof-4
> -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu99 ...snip
> many -Wxxx flags... -fexceptions -fasynchronous-unwind-tables -fipa-pure-const 
> -fstack-protector-strong -O2 -flto=auto -ffat-lto-objects -fexceptions -g
> -grecord-gcc-switches -pipe  -U_FORTIFY_SOURCE -Wp,-U_FORTIFY_SOURCE
> -Wp,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fPIC -pthread
> '-DLOCALEDIR="/usr/share/locale"'
> '-DDATADIR="/usr/share"' -DLIBVIRT_GLIB_BUILD
> -DGLIB_VERSION_MIN_REQUIRED=GLIB_VERSION_2_48 -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_48
> -MD -MQ libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -MF
> libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o.d -o
> libvirt-glib/libvirt-glib-1.0.so.0.4000.0.p/libvirt-glib-error.c.o -c
> ../libvirt-glib/libvirt-glib-error.c
>  ../libvirt-glib/libvirt-glib-error.c: error: -D_FORTIFY_SOURCE defined but value is too
> low [-Werror]
>  cc1: all warnings being treated as errors
>
>  So does anyone know what this error message would be coming from, and more
>  importantly how to make it go away :-) 
I've seen this happen with ccache is in use[1], which flips the
defines around, causing _FORTIFY_SOURCE to be undefined.  I've posted
a fix to redhat-rpm-config[2] to remedy this in the default flags to
work around the reordering; the additional -U was redundant anyway.

Sid

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2160275
[2] https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/237