issue regarding openblas for riscv bare metal system

[93c59]

I have configured the RISC-V toolchain using the following command:

./configure --prefix=path/to/inst_dir --target=riscv64-unknown-elf --with-arch=rv64imafd_zicsr --with-abi=lp64d --enable-multilib --with-languages=c,c++,fortran

Next, I built OpenBLAS using this RISC-V toolchain with the following command:

make TARGET=RISCV64_GENERIC CC=riscv64-unknown-elf-gcc FC=riscv64-unknown-elf-gfortran HOSTCC=gcc NO_SHARED=1 USE_THREAD=0 NO_AFFINITY=1 CFLAGS="-march=rv64imafd_zicsr -mabi=lp64d -mcmodel=medany -O2 -DOS_EMBEDDED" FCFLAGS="-march=rv64imafd_zicsr -mabi=lp64d -mcmodel=medany -O2" LDFLAGS="-lm"

The OpenBLAS build completed successfully, producing the following details:

• OS: [Not specified]
• Architecture: RISC-V 64-bit
• BINARY: 64-bit
• C compiler: GCC (Command and version: riscv64-unknown-elf-gcc (g04696df09) 14.2.0)
• Fortran compiler: GFORTRAN (Command and version: GNU Fortran (g04696df09) 14.2.0)
• Library Name: libopenblas_riscv64_generic-r0.3.28.dev.a (Single-threading)

To install the library, the following command can be used:

make PREFIX=/path/to/your/installation install

Note: Any flags passed during the build process must also be passed to the make install command to avoid installation errors.

I ran the following command to install OpenBLAS:

make install PREFIX=/home/ram/openblas_riscv/elf_openblas CC=riscv64-unknown-elf-gcc FC=riscv64-unknown-elf-gfortran NO_SHARED=1

The installation completed successfully.

However, when linking code using this RISC-V toolchain, I encountered multiple definition errors for standard functions like puts, atoi, and printf. For example:

/home/ram/openblas_riscv/riscv_zicsr/lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/ram/openblas_riscv/elf_openblas/lib/libopenblas.a(memory.o): in function `printf':
memory.c:(.text+0x8): undefined reference to `malloc'
memory.c:(.text+0x68): undefined reference to `free'
memory.c:(.text+0x1f2): undefined reference to `_impure_ptr'
memory.c:(.text+0x20c): undefined reference to `fwrite'

I am using the following commands for compiling and linking:

Compilation

riscv64-unknown-elf-gcc -march=rv64imafd_icsr -mabi=lp64d -mcmodel=medany -fno-builtin -fno-builtin-printf -fno-builtin-puts -fdata-sections -ffunction-sections -fno-builtin-memcmp -I<path_to_board_include> -I/home/ram/openblas_riscv/elf_openblas/include --specs=nano.specs --specs=nosys.specs -c <source_file.c> -o <output_object_file.o>

Linking

riscv64-unknown-elf-gcc -Wl,--gc-sections -Wl,-Map=<output_map_file.map> -nostartfiles -nostdlib -march=<arch> -mabi=<abi> -mcmodel=medany -T/<path_to_board>bsp/common/mbl.lds --L<path_to_board>bsp <object_files> -Wl,--start-group -l<board_specific_library> -lc -lgcc -lm -lopenblas -Wl,--end-group -L/home/ram/openblas_riscv/elf_openblas/lib -o <output_executable.elf>

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/openblas_riscv/elf_openblas/lib/libopenblas.a(memory.o): in function `puts':

memory.c:(.text+0x78): multiple definition of `puts'; /home/riscv/board/board-sdk-master/bsp/libboard.a(stdlib.o):/home/riscv/board/board-sdk-master/bsp/common/stdlib.c:912: first defined here

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/openblas_riscv/elf_openblas/lib/libopenblas.a(memory.o): in function `printf':

memory.c:(.text+0x7c): multiple definition of `printf'; /home/riscv/board/board-sdk-master/bsp/libboard.a(stdlib.o):/home/riscv/board/board-sdk-master/bsp/common/stdlib.c:937: first defined here

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/openblas_riscv/elf_openblas/lib/libopenblas.a(memory.o): in function `atoi':

memory.c:(.text+0x9c): multiple definition of `atoi'; /home/riscv/board/board-sdk-master/bsp/libboard.a(stdlib.o):/home/riscv/board/board-sdk-master/bsp/common/stdlib.c:250: first defined here

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: warning: build/gps_demo.elf has a LOAD segment with RWX permissions

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/openblas_riscv/elf_openblas/lib/libopenblas.a(memory.o): in function `alloc_malloc':

memory.c:(.text+0x8): undefined reference to `malloc'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: memory.c:(.text+0x68): undefined reference to `free'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/openblas_riscv/elf_openblas/lib/libopenblas.a(memory.o): in function `blas_memory_alloc':

memory.c:(.text+0x1f2): undefined reference to `_impure_ptr'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: memory.c:(.text+0x20c): undefined reference to `fwrite'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: memory.c:(.text+0x226): undefined reference to `fwrite'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: memory.c:(.text+0x23c): undefined reference to `fprintf'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: memory.c:(.text+0x250): undefined reference to `malloc'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: memory.c:(.text+0x260): undefined reference to `malloc'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/openblas_riscv/elf_openblas/lib/libopenblas.a(memory.o): in function `blas_memory_free':

memory.c:(.text+0x35e): undefined reference to `malloc'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: memory.c:(.text+0x366): undefined reference to `free'

/home/riscv/board/board-tools-master/toolchain/bin/../lib/gcc/riscv64-unknown-elf/14.2.0/../../../../riscv64-unknown-elf/bin/ld: /home/openblas_riscv/elf_openblas/lib/libopenblas.a(memory.o): in function `blas_shutdown':

memory.c:(.text+0x424): undefined reference to `free'

collect2: error: ld returned 1 exit status

[TommyMurphyTM1234]

Why are you using -nostdlib and --specs=nosys.specs if your code/library needs standard library functions? Seems contradictory and probably the root of your problem.

You haven't shown any issue with the riscv-gnu-toolchain here and the problem seems to be with how you're using the tools.

If you are having problems compiling OpenBLAS then you should probably ask about them upstream in that project. E.g.:

• https://github.com/OpenMathLib/OpenBLAS/issues?q=is%3Aissue+riscv
• https://github.com/OpenMathLib/OpenBLAS/discussions?discussions_q=riscv

[martin-frbg]

"bare metal" as I know it would seem to require him to have his onlyown implementations for standard library functions that would otherwise interact with an operating system, but the only experience we have with that on the OpenBLAS side is on Arm platforms. Does the riscv toolchain come with memory management support for "bare metal" platform too ?

[TommyMurphyTM1234]

"bare metal" as I know it would seem to require him to have his only implementations for standard library functions that would otherwise interact with an operating system, but the only experience we have with that on the OpenBLAS side is on Arm platforms. Does the riscv toolchain come with memory management support for "bare metal" platform too ?

The bare-metal RISC-V toolchain bundles Newlib which is a commonly used standard library for bare-metal resource constrained targets. But some bare-metal scenarios may involve the vendor or user providing everything from scratch via an appropriate HAL or board support package. If, for some reason, Newlib (or alternatives such as picolibc) is not suitable then somebody/something else will need to provide the required standard library support functionality.

The issue here is inappropriate use of the toolchain and not an issue with the toolchain itself so I am closing the issue.