One of the developers recently ran into linking issues when building executable statically linking with JDK static libraries and libjvm.a on Linux. Clang was used. The specific errors:

```
ld: error: <snip>/lib_static/server/libjvm.a(libjvm_relocatable.o): --icf=safe conservatively ignores SHT_LLVM_ADDRSIG [index 25] with sh_link=0 (likely created using objcopy or ld -r)
ld: error: <snip>/lib_static/lible.a(lible_relocatable.o): --icf=safe conservatively ignores SHT_LLVM_ADDRSIG [index 47] with sh_link=0 (likely created using objcopy or ld -r)
ld: error: <snip>/lib_static/libverify.a(libverify_relocatable.o): --icf=safe conservatively ignores SHT_LLVM_ADDRSIG [index 64] with sh_link=0 (likely created using objcopy or ld -r)
...
```

With some investigations, I found MaskRay's https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#icfall-and---icfsafe, which explained the issue quite clearly. In a short summary:

The `-Wl,--icf=safe` linker option cannot work well with binaries created using `ld -r` or `objcopy`. `--icf=safe` uses `.llvm_addrsig` section, which contains symbol indexes and `ld -r` or `objcopy` may change the the symbol table. That causes the linker errors referenced above.

When creating JDK static libraries and `libjvm.a` on linux using clang, we first use `ld -r` to partially link the related .o files. I think Magnus and the JDK build team have been exploring using `objcopy` to "hide" symbols as a general solution for symbol issues. So both `ld -r` and `objcopy` would be involved when building JDK and hotspot static libraries by default on linux using clang.

I found some existing solutions addressing similar issues in other cases removed the problematic `.llvm_addrsig` section. I discussed with MaskRay and removing the section seemed to be the right thing for now. My early testing confirmed it works properly.