From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id 0C4013858403 for ; Sun, 2 Jan 2022 17:29:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0C4013858403 Received: by mail-lj1-x231.google.com with SMTP id h21so40734771ljh.3 for ; Sun, 02 Jan 2022 09:29:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=cm8xQyKlaOJ9Y3fj9Fwz2N32y/gaHg2nFKZ6c3+S61M=; b=2FTe1O7+mYFp4sYbDSTq+6mYsq9BXjSUlxk6zH4PgrUdi09K2L5cqRZ+9Rvmi7nvvc QgwDeHHEtYpRwjQ+Fas1RZWw/q+wzqmfZQNP+ZImIz01YGXCM4rWeqF4ucw3qo6Ijq1W KJ/8JVmSMANIJmiO9/3TCxm3my4pgA24Xv1tFlTunGkr8wAR/ylim+NWPWfLm/I7l49L g8eR3H/gKO4Sd6mOcpMoWvi0+ssNHoJLwnIe9mDarqvnh+Ck6xZNtM0fDCAEjtlSnZfM 4/7ZxLQh5uCCmf7ke5vXOwqNymFZkDxWQzm8sq7PyO2RG1juyYtJRLuPv5fFXBM9MH4J sQTQ== X-Gm-Message-State: AOAM533veRzxR2KQThaHNuhvExLgUmKQe0NeT3Akef8AnEVSSliO218s mgKsXLSC0gApt7/nANfbL0tl1P5lOgw= X-Google-Smtp-Source: ABdhPJybpxHEL2WYOeVuTjfb+ruWeI70UWvlRONeWPZvaeYMae3Fa7emSCElZ4GJTZdcBp0zE2PI7w== X-Received: by 2002:a2e:9750:: with SMTP id f16mr25873646ljj.70.1641144551504; Sun, 02 Jan 2022 09:29:11 -0800 (PST) Received: from lahvuun.lan (93-76-191-141.kha.volia.net. [93.76.191.141]) by smtp.gmail.com with ESMTPSA id bu1sm1371556lfb.164.2022.01.02.09.29.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 Jan 2022 09:29:10 -0800 (PST) Date: Sun, 2 Jan 2022 19:29:10 +0200 From: Ilya Trukhanov To: libc-help@sourceware.org Subject: Dynamic loader path on x86_64 Message-ID: <20220102172910.au2emqbo5ntutxkk@lahvuun.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jan 2022 17:29:15 -0000 Hello! I'm building glibc-2.34 on x86_64 for a no-multilib prefix like so: $ mkdir build && cd build $ ../configure --prefix=/pfx $ make -j16 $ make install After looking at sysdeps/unix/sysv/linux/x86_64/ldconfig.h: #define SYSDEP_KNOWN_INTERPRETER_NAMES \ { "/lib/ld-linux.so.2", FLAG_ELF_LIBC6 }, \ { "/libx32/ld-linux-x32.so.2", FLAG_ELF_LIBC6 }, \ { "/lib64/ld-linux-x86-64.so.2", FLAG_ELF_LIBC6 }, I'd expect the loader to be installed to /pfx/lib64/ld-linux-x86-64.so.2, but it is instead installed to /pfx/lib/ld-linux-x86-64.so.2, breaking (at least) /pfx/bin/ldd, which gives me "not a dynamic executable" for all files. Strace hints at the problem: ... faccessat2(AT_FDCWD, "/pfx/lib/ld-linux.so.2", X_OK, AT_EACCESS) = -1 ENOENT (No such file or directory) faccessat2(AT_FDCWD, "/pfx/lib64/ld-linux-x86-64.so.2", X_OK, AT_EACCESS) = -1 ENOENT (No such file or directory) faccessat2(AT_FDCWD, "/pfx/libx32/ld-linux-x32.so.2", X_OK, AT_EACCESS) = -1 ENOENT (No such file or directory) ... Indeed, symlinking /pfx/lib64 to /pfx/lib makes it work. Is this some sort of multilib quirk? Aarch64 and riscv ldconfig.h seem to have theirs at /lib just fine. Is the lib64->lib symlink the intended way to solve this? Would things break if I simply patch ldconfig.h to add { "/lib/ld-linux-x86-64.so.2", FLAG_ELF_LIBC6 }? Is there better way to do this that I'm not aware of, maybe? Best, Ilya Trukhanov.