riscv-none-elf-ld: -shared not supported
Closed this issue · 7 comments
Description
While building the shared library (.so) for a risc-v based core, I am getting the following error reported by the linker:
riscv-none-elf-ld: -shared not supported
I want to know if the -shared option is supported by the toolchain. If not, is there any other way to create the .so file?
Versions
I am using the following version of the linker:
$ riscv-none-elf-ld --version
GNU ld (xPack GNU RISC-V Embedded GCC x86_64) 2.38
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
EDIT: Added gcc version that I'm using
$ riscv-none-elf-gcc --version
riscv-none-elf-gcc (xPack GNU RISC-V Embedded GCC x86_64) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Operating System:
16.04.1-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux
Assuming you can build a shared library with the RISC-V Embedded GCC compiler, how do you plan to dynamically load it on an application running on a bare metal board?
I'm not planning to load the shared library on board. Instead, I'm planning to call the symbols/functions present in the shared library via a wrapper written in python.
... via a wrapper written in python.
Python? Do you have Python on the bare metal board?
I'm not planning to load the shared library on board
Regardless how you plan to invoke it, a shared library must first be loaded into memory and this requires lots of processing. This is the job of a dynamic loader. Do you have such a thing for your bare metal application?
Python? Do you have Python on the bare metal board?
We are using JTAG interface to access our board, and the JTAG interface is controlled via python script. The python script is just an interface to call underlying C functions.
... a shared library must first be loaded into memory. Do you have such a thing for your bare metal application?
Correct me if I'm wrong, but isn't that the job of the linker itself? It should get the definition of the functions present in the shared library and put that information in the generated executable/hex.
Let me know if you need more information.
Correct me if I'm wrong, but isn't that the job of the linker itself? It should get the definition of the functions present in the shared library and put that information in the generated executable/hex.
It isn't the job of the linker alone, you also need a loader. On Linux it is ld.so.
On bare metal I am not aware of such a solution. Some years ago I worked with a friend on an experimental dynamic loader for Cortex-M targets, but using it was quite complicated.
If necessary, I can enable shared libraries in the linker build scripts, but I recommend you build your application statically.
I understand what you are trying to say. Let me see if I can build the application statically. Closing this issue for now. Thanks for your response.
BTW, I checked the build scripts and I could not find any explicit options to enable/disable the creation of shared libraries.
Exactly the same scripts create the arm-none-eabi-gcc toolcahin that allows the linker to create shared libraries and the riscv-none-elf-gcc that does not.
I would say that the RISC-V team did not enable shared libraries for the bare-metal toolchain.