C++ ld:错误：节：。data.rel.ro与其他relro节不连续

我正在使用

-ffunction sections

和

-gc sections

选项来优化应用程序，但ld无法链接到错误：

/home/yunxing.cyx/china-gcc-10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/collect2
-plugin /home/yunxing.cyx/china-gcc-10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/liblto_plugin.so
-plugin-opt=/home/yunxing.cyx/china-gcc-10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
-plugin-opt=-fresolution=/.vos/.ob-compile/tmp/yunxing.cyx/ccRgBV8r.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh --eh-frame-hdr -m elf_x86_64 -shared -o libmyapp.so -z noexecstack /lib/../lib64/crti.o /home/yunxing.cyx/china-gcc-10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/crtbeginS.o @/.vos/.ob-compile/tmp/yunxing.cyx/ccX1Yrmq
-L/home/yunxing.cyx/work/myapp/rpm/.compile -L/home/yunxing.cyx/china-gcc-10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0
-L/home/yunxing.cyx/china-gcc-10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64 -L/home/yunxing.cyx/china-gcc-10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../.. @/.vos/.ob-compile/tmp/yunxing.cyx/ccvpSZzo
-lgcc -lgcc_eh -lc -lgcc -lgcc_eh /home/yunxing.cyx/china-gcc-10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/crtendS.o /lib/../lib64/crtn.o                       

ld: error: section: .data.rel.ro is not contiguous with other relro sections 
ld: error: section: .dynamic is not contiguous with other relro sections 
ld: error: section: .got is not contiguous with other relro sections 
collect2: error: ld returned 1 exit status 
make[2]: *** [src/myserver/libmyapp.so] Error 1 
make[1]: *** [src/myserver/CMakeFiles/myapp.dir/all] Error 2 
make[1]: *** Waiting for unfinished jobs.... 
[100%] Built target myapp_static 
make: *** [all] Error 2

---

glibc

动态加载程序只支持一个

relro

部分，因此我能想到的唯一可能的解决方案（除了不使用

-ffunction部分或完全禁用饼图）是禁用：
-Wl，-z，norelro


至于原因，如果我们检查，我们会看到这样的代码

  if (_dl_phdr != NULL)
    for (const ElfW(Phdr) *ph = _dl_phdr; ph < &_dl_phdr[_dl_phnum]; ++ph)
      switch (ph->p_type)
    {
    // . . .
    case PT_GNU_RELRO:
      _dl_main_map.l_relro_addr = ph->p_vaddr;
      _dl_main_map.l_relro_size = ph->p_memsz;
      break;
    }

  /* Setup relro on the binary itself.  */
  if (_dl_main_map.l_relro_size != 0)
    _dl_protect_relro (&_dl_main_map);

if（\u dl\u phdr！=NULL）
对于（常数ElfW（Phdr）*ph=_dl_Phdr；ph<&u dl_Phdr[_dl_phnum]；++ph）
开关（ph->p_型）
{
// . . .
案例PT_GNU_RELRO：
_dl_main_map.l_relro_addr=ph->p_vaddr；
_dl_main_map.l_relro_size=ph->p_memsz；
打破
}
/*在二进制文件本身上重新安装*/
如果（_dl_main_map.l_relro_size！=0）
_dl_protect_relro（&_dl_main_map）；

因此，只有最后的
PT_GNU_RELRO
PHDR将受到保护。知道了这一点，就会出现错误，以防止潜在的安全问题

总是欢迎向
glibc
请求拉取以改进
relro
处理。
任何文档都提到此约束？