From owner-svn-src-head@FreeBSD.ORG Sun Sep 8 14:39:03 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1B8E87F0; Sun, 8 Sep 2013 14:39:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 942782104; Sun, 8 Sep 2013 14:39:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r88EcsFp080975; Sun, 8 Sep 2013 17:38:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r88EcsFp080975 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r88EcswG080974; Sun, 8 Sep 2013 17:38:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Sep 2013 17:38:54 +0300 From: Konstantin Belousov To: Dag-Erling Sm??rgrav Subject: Re: svn commit: r255385 - in head/etc: . etc.amd64 Message-ID: <20130908143854.GA41229@kib.kiev.ua> References: <201309080946.r889kNSX050568@svn.freebsd.org> <20130908110410.GZ41229@kib.kiev.ua> <86zjrnedp5.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d+OnLgn+wkzLMn3r" Content-Disposition: inline In-Reply-To: <86zjrnedp5.fsf@nine.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 14:39:03 -0000 --d+OnLgn+wkzLMn3r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 08, 2013 at 01:48:54PM +0200, Dag-Erling Sm??rgrav wrote: > Konstantin Belousov writes: > > There is no /lib32 on 64bit platforms. >=20 > It doesn't exist, but it's supported: >=20 > #ifdef COMPAT_32BIT > #undef STANDARD_LIBRARY_PATH > #undef _PATH_ELF_HINTS > #define _PATH_ELF_HINTS "/var/run/ld-elf32.so.hints" > /* For running 32 bit binaries */ > #define STANDARD_LIBRARY_PATH "/lib32:/usr/lib32" > #define LD_ "LD_32_" > #endif >=20 > > I do not understand why these pathes are neeeded, since compat32 rtld > > has proper default path built in >=20 > Did you read the log message? I am perfectly aware that the two lines > you're complaining about are a no-op; they're included mostly for > documentation purposes. However, if the code that uses them was made > unconditional (it is currently #ifdef COMPAT_32BIT), these lines would > eliminate the need to hardcode a special STANDARD_LIBRARY_PATH in > rtld-elf. Any line in libmap.conf cannot add to the standard search path. It only translates existing path. And, the standard path is specified by the ELF standard, which we try to follow. I.e., hardcoding STD_LIB_PATH in rtld is basically an external requirement. I see no reason not to remove #ifdef COMPAT_32BIT from the path_enumerate(). At least, it would make the rtld behaviour less puzzling. >=20 > > but if anything, /lib should be translated to /usr/lib32. >=20 > Irrelevant, because while rtld-elf won't find anything there it will > still find what it's looking for in /usr/lib32. Not irrelevant. If the 32bit binary is linked with "-z nodefaultlib -rpath /lib", /usr/lib32 would not be searched. This is not as silly as it looks, since intent is to provide some private version of the library which exists in /usr/lib. The non-existing path in standard search path is harmless, while translation of the existing path (in native environment) to non-existing path (in compat32 env) has some side effects. I am trying to point out that the line spelled as /lib /usr/lib32 is more reasonable. >=20 > These mappings are *not* applied to individual libraries; they are > applied to STANDARD_LIBRARY_PATH, LD_LIBRARY_PATH and the program's or > library's run-time search path (-rpath). >=20 > DES > --=20 > Dag-Erling Sm??rgrav - des@des.no --d+OnLgn+wkzLMn3r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iQIcBAEBAgAGBQJSLIv9AAoJEJDCuSvBvK1BZRgP/0thwgOVOI7a0FNtVVcQhXvc MmIPVsC+5Zyf9GoHfPenKioyBpi3nyNqNnamZ3TZ4PLoswXRAjoav/YSkOuDo//n x6BBA3GjjJRuIGVyBMFg8F3x8X9RfBbJostflEUekr+Ufcd04Yw7QeKbF+RLPAeR T7+KC0+FdCjY/+voITup8zrzHX0FiurUIjgqQUZQ3kNy5f1OeFhtxS66QG85WESA dJ4jml7TXrZJIoQvL8Mav/+ugeaRuyXSP0/jJB0LMNgRLaBpnGy44BtDM0UunhEQ DQxf7ohEKVVslaBKvyzs/L9Wxk1LjrCh/sOeZE0VXnvq+kULrwwbVLPGGiGR6Xx+ he8qKtxsPbp7IZamSCWcw9JH1mFFFIN/1xuaWavziB7mDw2qz1JF6MbEZDc3tSBt n1RkupPbuwUi6iG1vTAWxIEdZmFntpSa6o4/TkRLZQJpbeZikNyvUWUvJ6KLhrcQ F/y47cD1AJFIdGEk6fyEHHsWKNjAfQNuKDtFf5KyyoOxWSFDtqk9JV3x7J3Uv0mX fKk1oyjVLC5S63y9aFM/rC5btN7ifNQ6nbRmDarHyvNPMxOp5b1ZQ8D1sV7OWSlO 4ajUQfJA7RActBiC202IDjIItnvRG3YGRRbC1XfdWpKgM4FbmCM5toEqa0y768Rc ZN+rRIshGlzQmV7/5Rdc =4xnI -----END PGP SIGNATURE----- --d+OnLgn+wkzLMn3r--