On Fri, Sep 09 2022, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
> When building ports-gcc on riscv64 I get this kind of error:
>
> --8<--
> ld: error: relocation refers to a symbol in a discarded section: .LEHB30
>>>> defined in .libs/libcp1.o
>>>> referenced by connection.hh:72
>>>> (/usr/ports/pobj/gcc-8.4.0/gcc-8.4.0/libcc1/connection.hh:72)
>>>> .libs/libcp1.o:(.gcc_except_table+0x1A9)
>>>> referenced by connection.hh:72
>>>> (/usr/ports/pobj/gcc-8.4.0/gcc-8.4.0/libcc1/connection.hh:72)
>>>> .libs/libcp1.o:(.gcc_except_table+0x1AD)
> -->8--
>
> The checks in ld.lld try to implement the ELF specs in a strict way,
> but this causes problems on riscv[0] and other architectures (the
> comments in the diff with additional context below). The
> .gcc_except_table case has been fixed in newer clang releases[1] but
> I suspect gcc hasn't improved upstream - looking only at their bugzilla.
>
> One can work around this with -ffunction-sections so that
> .gcc_except_table is split and the parts pointing at discarded sections
> can be pruned. But this feels like a hack and would require egcc/eg++
> consumers to use it. AFAIK there is no documented knob to downgrade this
> kind of error to a warning.
>
> Hence the diff below, which happens to be the same proposal as in [0].
> I have split this case from the checks above, thinking that it would let
> me both document the workaround and lessen the risk of merge conflict.
> But I can merge the .gcc_except_table case with the checks above it if
> preferred.
>
> Thoughts? ok?
My follow-up lingered in the draft folder:
I have worked around this by using -ffunction-sections in the
lang/gcc/{8,11}. So far this issue hasn't popped up in
a lang/gcc/8,-c++ consumer port but since riscv64 uses clang as the
default compiler there aren't many of them. This diff can be ignored
for now.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
