很感谢你的参与，我尝试答复下这个问题，有不合理的地方，希望可以一起改进：

我是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我会检视合入， 再次感谢你的热心。