From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) by sourceware.org (Postfix) with ESMTPS id 878E73858C27 for ; Mon, 3 Jan 2022 17:31:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 878E73858C27 Received: by mail-qk1-x72e.google.com with SMTP id f138so31908716qke.10 for ; Mon, 03 Jan 2022 09:31:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=gX71+hjbxqnXtjRZvfS0kiOGRcfaPxZ85Cq3N3ndA+E=; b=FvaZuTfT1DqymNijkbMs3dnOYvBTqIKZ0Dt2QPhRIcFeythHf3TC7WW4DYF/z40Dd5 NKQSmszAJBwBPD5IfWjPz3AodKymxB4AKVLqNuST/vnWh0p/13G3wLJtnRDC3BliJBE2 PH9C6YocO5LL0Q8CFBw1whPm8h1O08lXV1xhjl7IaUsDw3Si/b6PPR2OAos7LYvHrRhj SDy+sZ5jDbkI+ry0EnxUiZ89mrAQc8yn1e0AFJkXxRffg4l/hAwd6GZbyAT77PWIb/PQ 6vAA8TOvfH4EqHBDSlIrrrAJwd+PSeqkT0KHu/n2Q2n938IG38zqIU7HWIXZeDeZphSy LB5A== X-Gm-Message-State: AOAM530FLQKaXrp7AEkW2/HaAthqe+1yyuMevq3XSk7bPyBvLRx3VNiq nHdFwACGyEW3GJxO/BAAiPSpfqEwnbdrDQ== X-Google-Smtp-Source: ABdhPJzEQcOPJQUFmHapb0JSCgLQcAZ48SjMEapYYjTy57nhH07fzAm9kP7gpCvwBw07ir2QEepXnA== X-Received: by 2002:a37:9d58:: with SMTP id g85mr29385374qke.745.1641231077023; Mon, 03 Jan 2022 09:31:17 -0800 (PST) Received: from ?IPV6:2804:431:c7ca:a350:6969:50a8:eab8:8f2f? ([2804:431:c7ca:a350:6969:50a8:eab8:8f2f]) by smtp.gmail.com with ESMTPSA id c7sm1209658qtd.62.2022.01.03.09.31.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Jan 2022 09:31:16 -0800 (PST) Message-ID: Date: Mon, 3 Jan 2022 14:31:15 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: Dynamic loader path on x86_64 Content-Language: en-US To: Ilya Trukhanov , Libc-help References: <20220102172910.au2emqbo5ntutxkk@lahvuun.lan> From: Adhemerval Zanella In-Reply-To: <20220102172910.au2emqbo5ntutxkk@lahvuun.lan> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Mon, 03 Jan 2022 17:31:19 -0000 On 02/01/2022 14:29, Ilya Trukhanov via Libc-help wrote: > 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: This is expected behavior and the idea is to allow 32-bit and 64-bit binaries to work on same installation. You can check the aclocal.m4 rule that selects the folder that install the loader: aclocal.m4: 296 dnl Default to slibdir named SLIBDIR instead of "lib", and rtlddir 297 dnl named RTLDDIR instead of "lib". This is used to put 64-bit 298 dnl libraries in /lib64. 299 dnl LIBC_SLIBDIR_RTLDDIR([slibdir], [rtlddir]) 300 AC_DEFUN([LIBC_SLIBDIR_RTLDDIR], 301 [test -n "$libc_cv_slibdir" || 302 case "$prefix" in 303 /usr | /usr/) 304 libc_cv_slibdir='/$1' 305 libc_cv_rtlddir='/$2' 306 if test "$libdir" = '${exec_prefix}/lib'; then 307 libdir='${exec_prefix}/$1'; 308 # Locale data can be shared between 32-bit and 64-bit libraries. 309 libc_cv_complocaledir='${exec_prefix}/lib/locale' 310 fi 311 ;; 312 esac]) As you can see, you can override by defining libc_cv_slibdir at configure time: $ libc_cv_slibdir=/lib64 ../../glibc-git/configure --prefix=/usr $ make -j24 $ make install DESTDIR=$PWD/install $ find install/ -iname ld-linux-x86-64.so.2 install/lib64/ld-linux-x86-64.so.2 However the ldd iss is unexpected, since it should handle it by rewriting the rtld path: elf/Makefile 756 ldd-rewrite = -e 's%@RTLD@%$(rtlddir)/$(rtld-installed-name)%g' \ 757 -e 's%@VERSION@%$(version)%g' \ 758 -e 's|@PKGVERSION@|$(PKGVERSION)|g' \ 759 -e 's|@REPORT_BUGS_TO@|$(REPORT_BUGS_TO)|g' \ 760 -e 's%@TEXTDOMAINDIR@%$(localedir)%g' 761 762 ifeq ($(ldd-rewrite-script),no) 763 define gen-ldd 764 LC_ALL=C sed $(ldd-rewrite) < $< > $@.new 765 endef 766 else 767 define gen-ldd 768 LC_ALL=C sed $(ldd-rewrite) < $< \ 769 | LC_ALL=C sed -f $(patsubst $(..)/%,/%,$(..)$(ldd-rewrite-script)) > $@.new 770 endef 771 endif And x86_64 does instruct make to rewrite it: $ git grep -w ldd_rewrite_script | grep x86_64 sysdeps/unix/sysv/linux/x86_64/configure:ldd_rewrite_script=sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed sysdeps/unix/sysv/linux/x86_64/configure.ac:ldd_rewrite_script=sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed You can see that a normal installation will indeed set all the possible loaders on the RTDLIST: $ cat install/usr/bin/ldd [...] 29 RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2" [...] > > ... > 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. aarch64, I am not sure about riscv, does not really have the concept of multilib since A32 supports is not strictly required by ISA. > > Is the lib64->lib symlink the intended way to solve this? It is a way to solve afaiu yes. > > 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? I think it is better to just use libc_cv_slibdir if you not intend to use 32-bit libc along with the 64-bit install. I would also check on how each distro does that, I know debian based system does patch glibc to support their own internal triple organization. > > Best, > Ilya Trukhanov.