From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F22BF3858403; Mon, 3 Jan 2022 21:32:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F22BF3858403 From: "wilson at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/103889] gccgo is unable to find its standard library by default on 64-Bit RISC-V due to musl not using multilib but still uses t-linux Date: Mon, 03 Jan 2022 21:32:50 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 11.2.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: wilson at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2022 21:32:51 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D103889 Jim Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wilson at gcc dot gnu.org --- Comment #14 from Jim Wilson --- The RISC-V ABI defines 6 different ABIs currently (not including rv32e support), so the old /lib and /lib64 distinction isn't enough. We define 6 different directories where the libraries can be, depending on the ABI in u= se.=20 For rv64/lp64d, the most common one, they go in /lib64/lp64d. Desktop linux does not use all of these ABIs, but embedded linux does. Alibaba/T-Head incidentally has written linux kernel and qemu support for running 32-bit code on a rv64 kernel, but I don't know if they have hardware that supports this yet, and don't know if they are multilibbing/multiarching yet. I think it is only a matter of time before we have to support both 32= -bit and 64-bit code on rv64 systems. Anyways, the first thing I would try is to make some links. You can make /lib64 a link to /lib, and make a /lib/lp64d link that points back at lib.= =20 Hence /lib64/lp64d will point at /lib. Likewise for /usr/lib64/lp64d to po= int at /usr/lib. Then see if gccgo works. Some linux distros already have the= se links. Adding these links to the OS might be the simplest solution if it works. If you don't link the symlink idea, then we probably need a new t-linux-musl file. And if you are using GNU Binutils, then you need GNU ld changes, sin= ce it is hardwired to use the same dirs. And if you are using glibc then you = need glibc changes too, but you mentioned musl so this doesn't apply to you, but would apply to others if they want the same kind of changes for another lin= ux distro. On a Fedora RISC-V system [wilson@fedora-riscv /]$ ls -lt lib64 lrwxrwxrwx. 1 root root 9 Aug 12 2020 lib64 -> usr/lib64 [wilson@fedora-riscv /]$ cd /usr/lib64 [wilson@fedora-riscv lib64]$ ls -lt lp64d lrwxrwxrwx. 1 root root 1 Aug 4 07:18 lp64d -> . [wilson@fedora-riscv lib64]$=20 So both /lib64/lp64d and /usr/lib64/lp64d work, and point to the same place= .=