Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

> I'm kind of torn on this one: this has been around for a while and > dropping it would be an ABI break, but the feedback from distro folks is > pretty consistently that multlib is broken on RISC-V. If it's really > unusably broken then I could buy the argument that there's no binaries >

Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

On 2022-07-14, Palmer Dabbelt wrote: On Mon, 20 Jun 2022 20:48:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote: On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng wrote: Generally I agree we should fix that by GCC driver rather than ld emulation, but I think this should be reverted with the -L path

Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

On Mon, 20 Jun 2022 20:48:50 PDT (-0700), gcc-patches@gcc.gnu.org wrote: On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng wrote: Generally I agree we should fix that by GCC driver rather than ld emulation, but I think this should be reverted with the -L path fix, otherwise that will break multilib

Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

On Mon, Jun 20, 2022 at 1:21 AM Kito Cheng wrote: > > Generally I agree we should fix that by GCC driver rather than ld > emulation, but I think this should be reverted with the -L path fix, > otherwise that will break multilib on GNU toolchain for linux > immediately? Thanks for the good

Re: [PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

Generally I agree we should fix that by GCC driver rather than ld emulation, but I think this should be reverted with the -L path fix, otherwise that will break multilib on GNU toolchain for linux immediately? On Wed, Jun 15, 2022 at 4:00 PM Fangrui Song via Gcc-patches wrote: > > This reverts

[PATCH] Revert "[PATCH] RISC-V: Use new linker emulations for glibc ABI."

This reverts commit 37d57ac9a636f2235f9060e84fb8dd7968abd1dc. The resolution to https://sourceware.org/bugzilla/show_bug.cgi?id=22962 let GCC pass -m emulation to ld and let the ld emulation configure default library paths. This scheme is problematic: * It's not ld's business to specify default

Re: [PATCH] RISC-V: Use new linker emulations for glibc ABI.

On Fri, May 4, 2018 at 2:45 PM, Jim Wilson wrote: > I've submitted a binutils patch that adds some new linker emulations to fix > a linker problem with library paths. The rv64/lp64d linker looks in /lib64 > when glibc says it should look in /lib64/lp64d. To make the binutils

[PATCH] RISC-V: Use new linker emulations for glibc ABI.

I've submitted a binutils patch that adds some new linker emulations to fix a linker problem with library paths. The rv64/lp64d linker looks in /lib64 when glibc says it should look in /lib64/lp64d. To make the binutils patch work, I had to add 4 new emulations because we have 6 ABIs. This