If I'm using -fstack-protector-all, it is overwrited by the build system which adds -stack-protector-strong: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DG_DISABLE_SINGLE_INCLUDES -pthread -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I../.. -O2 -march=x86-64 -msse4.2 -fno-strict-overflow -fstack-protector-all -fstack-check=specific -fPIE -pie -pipe -funsigned-char -fPIC -Wall -Wextra -Wstrict-prototypes -Wno-unused-parameter -Wno-sign-compare -Wno-pointer-sign -Wno-missing-field-initializers -Wno-unused-result -fstack-protector-strong -c -o libhexchatcommon_a-plugin-identd.o `test -f 'plugin-identd.c' || echo './'`plugin-identd.c In my case CFLAGS="-O2 -march=x86-64 -msse4.2 -fno-strict-overflow -fstack-protector-all -fstack-check=specific -fPIE -pie"
(In reply to Agostino Sarubbo from comment #0) > If I'm using -fstack-protector-all, it is overwrited by the build system > which adds -stack-protector-strong: > --disable-stack-protector
Maintainer, you should add --disable-stack-protector in the ebuild and let users manage it via their cflags. Thanks
(In reply to Agostino Sarubbo from comment #2) > Maintainer, you should add --disable-stack-protector in the ebuild and let > users manage it via their cflags. Thanks hexchat defaults to using -fstack-protector-strong. This gives the application some stack smashing protection. Disabling this protection simply so other users can invoke a strong for is not a correct fix. Therefore, adding --disable-stack-protector to the ebuild is not the correct fix here. A correct fix would allow users to override -fstack-protector-strong while keeping the flag for users who do not explicitly specify a preference.
Do whatever you think is fine to avoid override
Fixed with commit https://github.com/gentoo/gentoo/commit/d88256e2f8a6cc6f808fdd665f615a91d213e959
(In reply to nvinson234 from comment #5) > Fixed with commit > https://github.com/gentoo/gentoo/commit/ > d88256e2f8a6cc6f808fdd665f615a91d213e959 will the commit go into upstream as well?
(In reply to Agostino Sarubbo from comment #6) > (In reply to nvinson234 from comment #5) > > Fixed with commit > > https://github.com/gentoo/gentoo/commit/ > > d88256e2f8a6cc6f808fdd665f615a91d213e959 > > will the commit go into upstream as well? Not sure. The patch has already been offered to upstream.
