From owner-freebsd-stable@FreeBSD.ORG Thu May 31 09:59:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A46EE106566B for ; Thu, 31 May 2012 09:59:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 22E338FC0C for ; Thu, 31 May 2012 09:59:02 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q4V9wlJv012160; Thu, 31 May 2012 12:58:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q4V9wlpk032573; Thu, 31 May 2012 12:58:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q4V9wluH032572; Thu, 31 May 2012 12:58:47 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 31 May 2012 12:58:47 +0300 From: Konstantin Belousov To: Oliver Fromme Message-ID: <20120531095847.GN2358@deviant.kiev.zoral.com.ua> References: <201205301615.q4UGFxSF051308@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f7rhGhcaiuL9D15N" Content-Disposition: inline In-Reply-To: <201205301615.q4UGFxSF051308@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: i386 binaries on amd64: ldconfig problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 09:59:04 -0000 --f7rhGhcaiuL9D15N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 30, 2012 at 06:15:59PM +0200, Oliver Fromme wrote: > Hi, >=20 > I've recently migrated my workstation from i386 to amd64 > (finally, because I neeed to go beyond 4 GB RAM). The > transition went smoothly so far, except for one thing: > I need to use several old i386 binaries, which all work > well except for one: olvwm. >=20 > $ uname -rsm > FreeBSD 8.3-STABLE-20120528 amd64 >=20 > $ olvwm > /libexec/ld-elf.so.1: /usr/local/lib/libXpm.so.4: unsupported file layout >=20 > $ file olvwm > olvwm: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), > dynamically linked (uses shared libs), for FreeBSD 8.2 (802502), stripped >=20 > $ ldd olvwm > olvwm: > libXpm.so.4 =3D> not found (0x0) > libolgx.so.3 =3D> /usr/local/lib32/compat/libolgx.so.3 (0x280d100= 0) > libXext.so.6 =3D> not found (0x0) > libX11.so.6 =3D> not found (0x0) > libm.so.5 =3D> /usr/lib32/libm.so.5 (0x280df000) > libc.so.7 =3D> /usr/lib32/libc.so.7 (0x280f9000) >=20 > $ ldconfig -32 -r | head -2 > /var/run/ld-elf32.so.hints: > search directories: /usr/lib32:/usr/local/lib32:/usr/local/lib32/= compat >=20 > $ ldconfig -32 -r | egrep 'libXpm|libXext|libX11' > 190:-lXpm.4 =3D> /usr/local/lib32/compat/libXpm.so.4 > 192:-lXext.6 =3D> /usr/local/lib32/compat/libXext.so.6 > 193:-lX11.6 =3D> /usr/local/lib32/compat/libX11.so.6 >=20 > So, the 32bit libraries are there, ldconfig knows about them, > but the runtime linker does not, apparently. >=20 > Interestingly, it works when I force the library path (this > is currently the work-around that I'm using): >=20 > LD_32_LIBRARY_PATH=3D/usr/local/lib32/compat ldd olvwm > olvwm: > libXpm.so.4 =3D> /usr/local/lib32/compat/libXpm.so.4 (0x280d1000) > libolgx.so.3 =3D> /usr/local/lib32/compat/libolgx.so.3 (0x280e100= 0) > libXext.so.6 =3D> /usr/local/lib32/compat/libXext.so.6 (0x280ef00= 0) > libX11.so.6 =3D> /usr/local/lib32/compat/libX11.so.6 (0x280fe000) > libm.so.5 =3D> /usr/lib32/libm.so.5 (0x28216000) > libc.so.7 =3D> /usr/lib32/libc.so.7 (0x28230000) > libxcb.so.2 =3D> /usr/local/lib32/compat/libxcb.so.2 (0x2834b000) > libXau.so.6 =3D> /usr/local/lib32/compat/libXau.so.6 (0x28362000) > libXdmcp.so.6 =3D> /usr/local/lib32/compat/libXdmcp.so.6 (0x28365= 000) > libpthread-stubs.so.0 =3D> /usr/local/lib32/compat/libpthread-stu= bs.so.0 (0x2836a000) > librpcsvc.so.5 =3D> /usr/lib32/librpcsvc.so.5 (0x2836c000) >=20 > But actually I shouldn't have to use LD_32_LIBRARY_PATH. > I mean, it's ldconfig's job to configure the directories for > locating the libraries. >=20 > What is wrong here? The library search order is LD_{32}_LIBRARY_PATH, then DT_RPATH from the binary, then hints, then /lib:/usr/lib. So if rpath of the binary contains /usr/local/lib, you get /usr/local/lib before hints. Rtld uses only the search path from the hints file. When a library with the matched name found, rtld tries to load it. Regardless of the result of the load attempt, further components of the search path list are not tried. Look at the olvwm binary with readelf and see whether DT_RPATH specifies /usr/local/lib. --f7rhGhcaiuL9D15N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk/HQNcACgkQC3+MBN1Mb4gVcACdHedoV8m3niD2mLPyMmOJy0KF TaoAoI9K/PuiqY1gX3XSn4ntV58vFI0e =YYTs -----END PGP SIGNATURE----- --f7rhGhcaiuL9D15N--