https://sourceware.org/bugzilla/show_bug.cgi?id=28684
Bug ID: 28684 Summary: [RISCV] 32-bit --enable-targets=all build breakage issue Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: nelsonc1225 at sourceware dot org Target Milestone: --- The 32-bit build failed again when --enable-targets=all, the original discussion was here, https://sourceware.org/pipermail/binutils/2021-November/118485.html For now, the dis-assembler (objdump) need to call the riscv architecture parser from bfd/elfxx-riscv.c (https://sourceware.org/pipermail/binutils/2021-November/118444.html), but this will break the 32-bit host --enable-targets=all build when building the libopcodes.a, [Copied from Alan's comments] usr/local/bin/ld: ../opcodes/.libs/libopcodes.a(riscv-dis.o): in function `riscv_disassemble_insn': /home/alan/src/binutils-gdb/opcodes/riscv-dis.c:541: undefined reference to `riscv_multi_subset_supports' /usr/local/bin/ld: ../opcodes/.libs/libopcodes.a(riscv-dis.o): in function `riscv_get_disassembler': /home/alan/src/binutils-gdb/opcodes/riscv-dis.c:892: undefined reference to `riscv_release_subset_list' /usr/local/bin/ld: /home/alan/src/binutils-gdb/opcodes/riscv-dis.c:893: undefined reference to `riscv_parse_subset' collect2: error: ld returned 1 exit status make[4]: *** [Makefile:940: objdump] Error 1 As I known, there are two solutions could fix the problem, The first one was suggested by Alan Modra, and the idea is great - don't compile some opcodes files when bfd is 32-bit only, https://sourceware.org/pipermail/binutils/2021-November/118500.html https://sourceware.org/pipermail/binutils/2021-December/118751.html But seems like this caused the simulator and gdb build failed, when building bfd in 32-bit mode. Therefore, Andrew Bugress have a proposed solution to make gdb can build as usual, https://sourceware.org/pipermail/gdb-patches/2021-December/184365.html At the meantime, Jim Wilson also remind us that my previous RFC patch may works, and then we probably won't need the extra gdb fixes, and the idea of solution was also came from him, https://sourceware.org/pipermail/binutils/2021-November/118498.html I'm OK that we can commit Andrew's gdb patch first, and then probably spend some times to make sure if my RFC patch do works. If so, then we can revert the gdb patch at that time. I collect all the information here, in case I forgot the details when coming back to see this issue again, or someone is interested and try to resolve it. Thanks Nelson -- You are receiving this mail because: You are on the CC list for the bug.