https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92030
--- Comment #2 from Alexander Nikulin <anikulin at dlink dot ru> --- (In reply to Richard Biener from comment #1) > You're doing it behind the back of the compiler - maybe use > __attribute__((alias("abc1"))) instead? Hi Richard, yes, I did. It declares global symbol 'abc2': ----------------------------------------- -#APP - .equiv abc2, abc1 - + .globl abc2 + abc2 = abc1 .rdata .align 2 ----------------------------------------- 00411010 d abc1 00411010 D abc2 ^ and it works with my snippet: @abc1 = 0x411010, abc2 = 0x411010, @abc2 = 0x411010 But as I understood, the developers would like to have a static alias-symbol exactly. Building FRR with __attribute__((alias(...))): extern struct memtype MTYPE_##name[1] __attribute__((alias("_mt_" #name))); produces the expected: .../grammar_sandbox.c:38: multiple definition of `MTYPE_CMD_TOKENS' .../command_graph.c:29: first defined here Am agreed that the .equiv trick may be treated as a hack, but I can not offer a valid replacement. And it works fine on x86_64: (Debian 8.2.0-16), i686: (Debian 6.3.0-18+deb9u1), very ancient xscale/armv5b: (gcc-4.4.3). Now I have no aarch64 board to check a compiled binary, but I see LO calls for abc2 in the generated asm. If this is not a compiler bug but wrong coding approach, could you please offer the decision which provides "static" aliases? Thanks!