很感谢你的参与，我尝试答复下这个问题，有不合理的地方，希望可以一起改进：
我是SUSE的毛晨曦，目前正在从事基于欧拉的发行版的开发和调研工作。
在开发的过程当中，关于GCC_secure的相关问题，想请教一下社区的开发者和维护者。后续我想会在GCC_secure这个包上面做一些开发维护工作。
Ø
Gcc_secure这个软件产生的背景是，需要对所有gcc编译的软件添加安全编译选项，
Ø
最开始的方案是选择修改rpm CFLAGS等编译选项，但发现无法覆盖所有，特别是没有makefile，直接使用脚本或其他方式构建的软件。
Ø
Gcc_secure的方案很粗暴，但有效，也在尝试改进方案。
根据我对于GCC _secure包的理解，GCC_secure包主要完成了下面几项工作：
1. 在gcc_secure包中增加了部分安全相关的编译参数，如pic/pie/fsprotect等，目的是增强整个openEuler的安全性
2. 增加了fsigned-char参数，为了保证arm64和X86的平台可移植性。
3. 在gcc_secure中定义了一个exclude名单，这个名单是在project config中进行定义的，里面包含了大约几十个包
Ø
这里的描述准确，恰恰是gcc_secure的功能，
Ø
关于gcc_secure的实现，有一些不太了解的地方想请开发者、维护者帮我理清一下。
1.
gcc_exclude的这个名单，是否是因为一些已知问题，才将这些软件包放在exclude的名单中？后续时候会根据版本演进，逐渐将这些包也使用gcc_secure的方式进行编译，如果开发者或维护者已经有相关计划或规划，烦请分享一下相关计划，后续可以共同解决这个问题，使得编译一致化。
Ø
Exclude名单是在日常处理时，发现的不能使用gcc_secure，或只能使用某一个或几个安全编译选项，
这个早期的方案现在看来导致整个系统的构建极其混乱，需要整改。
2.
在gcc_secure中增加fsigned-char使得ARM64的行为与X86一致，是否可以从源代码的层面解决会更加彻底一些，最终将fsigned-char从gcc_secure中移除。这方面我已经做了一些初步的工作，已经提交到社区。如果获得批准，后续我也会继续完善这方面工作。
Ø
非常赞成你的观点，源码层面的问题，就应该由开发者在源码层面闭环掉，而不应该让整个编译系统兜底。
几个PR我会检视合入，
再次感谢你的热心。
发件人: Chenxi Mao [mailto:chenxi.mao@suse.com]
发送时间: 2021年11月15日
17:31
收件人: dev@openeuler.org
抄送: Chenxi Mao <chenxi.mao@suse.com>
主题: [Dev] 关于欧拉操作系统gcc_secure包问题的讨论
Hi
各位尊敬的开发者和维护者：
您好，
我是SUSE的毛晨曦，目前正在从事基于欧拉的发行版的开发和调研工作。
在开发的过程当中，关于GCC_secure的相关问题，想请教一下社区的开发者和维护者。后续我想会在GCC_secure这个包上面做一些开发维护工作。
根据我对于GCC _secure包的理解，GCC_secure包主要完成了下面几项工作：
1. 在gcc_secure包中增加了部分安全相关的编译参数，如pic/pie/fsprotect等，目的是增强整个openEuler的安全性
2. 增加了fsigned-char参数，为了保证arm64和X86的平台可移植性。
3. 在gcc_secure中定义了一个exclude名单，这个名单是在project config中进行定义的，里面包含了大约几十个包
关于gcc_secure的实现，有一些不太了解的地方想请开发者、维护者帮我理清一下。
1. gcc_exclude的这个名单，是否是因为一些已知问题，才将这些软件包放在exclude的名单中？后续时候会根据版本演进，逐渐将这些包也使用gcc_secure的方式进行编译，如果开发者或维护者已经有相关计划或规划，烦请分享一下相关计划，后续可以共同解决这个问题，使得编译一致化。
2. 在gcc_secure中增加fsigned-char使得ARM64的行为与X86一致，是否可以从源代码的层面解决会更加彻底一些，最终将fsigned-char从gcc_secure中移除。这方面我已经做了一些初步的工作，已经提交到社区。如果获得批准，后续我也会继续完善这方面工作。
初步提交的PR如下：
烦请社区维护者审阅
相关问题在gitee上的地址：
Chenxi