Palmer Dabbelt wrote: > diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h > new file mode 100644 > index 0000000..045f6cc > --- /dev/null > +++ b/gcc/config/riscv/linux.h > [...] > +#define GLIBC_DYNAMIC_LINKER "/lib" XLEN_SPEC "/" ABI_SPEC "/ld.so.1"
[with XLEN_SPEC being either 32 or 64 and ABI_SPEC being one of ilp32, ilp32f, ilp32d, lp64, lp64f, lp64d] Hello everybody, I am not fully happy with the way the dynamic linker path (which gets embedded into every Linux executable built by gcc and therefore cannot be changed later) is defined here. The dynamic linker path must be unique over all platforms for which a Linux port exists to make multiarch installations (i.e. having dynamically linked binaries for multiple architectures/ABIs in the same root filesystem) possible. The path specifier as cited above contains nothing that makes the linker path inherently specific to RISC-V. While there is AFAIK no other architecture that currently uses exactly this specific linker path model with the ABI specifier as a separate subdirectory (instead of encoding it into the filename), so that there technically isn't a naming conflict, I think that we should follow the convention of the other "modern" Linux architectures, which all include the architecture name in their linker path: * arm64: /lib/ld-linux-aarch64.so.1 * armhf: /lib/ld-linux-armhf.so.3 * ia64: /lib/ld-linux-ia64.so.2 * mips n64: /lib64/ld-linux-mipsn8.so.1 * nios2: /lib/ld-linux-nios2.so.1 * x86_64: /lib64/ld-linux-x86-64.so.2 So the actual ld.so binary should be called something like "ld-linux-rv.so.1" instead of just "ld.so.1". With everything else staying the same, that would give us a dynamic linker path along the lines of "/lib64/lp64f/ld-linux-rv.so.1" for an RV64G system. Changing the linker path is of course an incompatible change, but RISC-V gcc support as submitted upstream now already incoporates a number of incompatible changes to the previous development versions (including a different dynamic linker path than older riscv-gcc versions), so moving from the previous development versions to upstream results in incompatible binaries anyway, therefore IMHO now is the time to get these things sorted out once for all. Regards, Karsten -- Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung sowie der Markt- oder Meinungsforschung.
