Open aaroneiche opened 2 months ago
I managed to find an answer that seems to have at least gotten me through compiling.
https://forums.raspberrypi.com/viewtopic.php?t=84506:
Lowering the optimization flag to -O2 fixes the issue. Still wondering why the programmers assumed that 'memset' is available when other flags indicates that no system/default libraries are to use.
I put this in under my changes to LDFLAGS and the compiling completed without complaint.
CFLAGS += -O2
I'll work on a PR.
Hi and thank you. This is really strange. I will make some tests when I find some time. There must be a better solution, I hope.
I'll note here additionally that the flag makes compiling work, but the code doesn't actually run. I'm not entirely sure why - I'll continue to explore.
I think that's because of the rv32imac flag. The ch32v003 doesn't actually support this instruction set.
Ahh yes, that makes sense. I'm compiling for the wrong thing. I am unfortunately back to unsuccessfully compiling on Apple Silicon/arm64.
aeiche@Aarons-MacBook-Pro tiny_tris % make all
Building tiny_tris.elf ...
/opt/homebrew/Cellar/riscv-gnu-toolchain/main/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: /opt/homebrew/Cellar/riscv-gnu-toolchain/main/lib/gcc/riscv64-unknown-elf/13.2.0/libgcc.a(div.o): ABI is incompatible with that of the selected emulation:
target emulation `elf64-littleriscv' does not match `elf32-littleriscv'
/opt/homebrew/Cellar/riscv-gnu-toolchain/main/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: failed to merge target specific data of file /opt/homebrew/Cellar/riscv-gnu-toolchain/main/lib/gcc/riscv64-unknown-elf/13.2.0/libgcc.a(div.o)
/opt/homebrew/Cellar/riscv-gnu-toolchain/main/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: /var/folders/v8/dwyhdmqn68bf9f2rm974l_lw0000gn/T//ccknxKLg.ltrans0.ltrans.o: in function `blitzSprite_TTRIS':
/Users/aeiche/Documents/Personal/Electronics Projects/CH32V003-GameConsole/software/tiny_tris/tiny_tris.c:499:(.text.blitzSprite_TTRIS+0x48): undefined reference to `__mulsi3'
/opt/homebrew/Cellar/riscv-gnu-toolchain/main/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: /Users/aeiche/Documents/Personal/Electronics Projects/CH32V003-GameConsole/software/tiny_tris/tiny_tris.c:500:(.text.blitzSprite_TTRIS+0x60): undefined reference to `__mulsi3'
/opt/homebrew/Cellar/riscv-gnu-toolchain/main/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: /Users/aeiche/Documents/Personal/Electronics Projects/CH32V003-GameConsole/software/tiny_tris/tiny_tris.c:505:(.text.blitzSprite_TTRIS+0x8a): undefined reference to `__mulsi3'
/opt/homebrew/Cellar/riscv-gnu-toolchain/main/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: /var/folders/v8/dwyhdmqn68bf9f2rm974l_lw0000gn/T//ccknxKLg.ltrans0.ltrans.o: in function `recupe_SCORES_TTRIS.part.0':
/Users/aeiche/Documents/Personal/Electronics Projects/CH32V003-GameConsole/software/tiny_tris/tiny_tris.c:638:(.text.recupe_SCORES_TTRIS.part.0+0x4a): undefined reference to `__mulsi3'
/opt/homebrew/Cellar/riscv-gnu-toolchain/main/lib/gcc/riscv64-unknown-elf/13.2.0/../../../../riscv64-unknown-elf/bin/ld: /var/folders/v8/dwyhdmqn68bf9f2rm974l_lw0000gn/T//ccknxKLg.ltrans0.ltrans.o: in function `main':
/Users/aeiche/Documents/Personal/Electronics Projects/CH32V003-GameConsole/software/tiny_tris/tiny_tris.c:362:(.text.startup.main+0x45e): undefined reference to `memset'
collect2: error: ld returned 1 exit status
make: *** [tiny_tris.elf] Error 1
I think it's clearly a linker issue, though I'm not really sure how to resolve it.
I have no idea at the moment ;-(
Did you perhaps use a different linker script or include other libraries? I don't know where the .text.startup.main comes from.
I'm not sure if its worth reopening issue #1 or just starting a new one, I'm running into a similar build error trying to build on an M1 MBP running Ventura (macOS 13.6.7)
I added the following to the makefile to fix an environment compiling error:
But otherwise the makefile is as it was. I haven't been able to figure out a fix other than what's already addressed in issue #1. (and that's in the makefile already, obvious)