From owner-freebsd-amd64@FreeBSD.ORG Mon Sep 3 12:30:19 2012 Return-Path: Delivered-To: freebsd-amd64@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B22F3106564A for ; Mon, 3 Sep 2012 12:30:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8317F8FC08 for ; Mon, 3 Sep 2012 12:30:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q83CUJF0069757 for ; Mon, 3 Sep 2012 12:30:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q83CUJkn069741; Mon, 3 Sep 2012 12:30:19 GMT (envelope-from gnats) Date: Mon, 3 Sep 2012 12:30:19 GMT Message-Id: <201209031230.q83CUJkn069741@freefall.freebsd.org> To: freebsd-amd64@FreeBSD.org From: Konstantin Belousov Cc: Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Konstantin Belousov List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Sep 2012 12:30:19 -0000 The following reply was made to PR amd64/171250; it has been noted by GNATS. From: Konstantin Belousov To: David Naylor Cc: freebsd-gnats-submit@freebsd.org Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries Date: Mon, 3 Sep 2012 15:26:50 +0300 --7FDnRloC5L6+fPHS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 03, 2012 at 02:01:43PM +0200, David Naylor wrote: > On Sunday, 2 September 2012 17:57:55 Konstantin Belousov wrote: > > On Sun, Sep 02, 2012 at 12:42:43PM +0000, David Naylor wrote: > > > ldd32 does not find libraries, yet ldconfig lists them as known. > > >=20 > > > # ldconfig -32 -r | grep directories > > >=20 > > > search directories: > > > /usr/lib32:/usr/local/lib32:/usr/local/lib32/wine > >=20 > > You should also look at the DT_RPATH and DT_RUNPATH tags in your binary. > > I suspect that there is some path hardcoded which points to the > > native 64bit libraries dir. >=20 > # elfdump -d libcups.so.2 > > entry: 9 > d_tag: DT_RPATH > d_val: /usr/lib:/usr/local/lib > > # elfdump -a libcups.so.2 | grep DT_RUNPATH > ... >=20 > As you suspected the paths are hardcoded. However, since this is a 32bit= =20 > library (and compiled in a i386 chroot) on a 64bit system I would have=20 > expected the dynamic linker to translate /usr/lib to /usr/lib32, or to pr= epend=20 > it. =20 >=20 > > If my theory holds, ths explicit use of LD_32_LIBRARY_PATH helps because > > the env var path has precedence over the path from tag. >=20 > If my expectation, mentioned above, is wrong then please close this bug. = I'm=20 > happy to continue using LD_32_LIBRARY_PATH to enduce the correct behaviou= r. =20 >=20 > Thanks for your quick reply. I have a symphathy to the idea that ld-elf32.so.1 should translate well-kno= wn pathes from DT_RPATH into their 32bit compat synonims. That is, /lib and /usr/lib probably should be interpreted as /lib32 and /usr/lib32. On the other hand, I do not know what to do with non-default pathes, that is /usr/local/lib in your case. Please note that some library can be find there for many reasons, and I cannot imagine a sane way to translate to 32bit compat path without involving some additional config. This is closely related to non-existent multiarch support in ports, which cannot even start happens without working cc -m32. I think your PR shall be postponed instead of being closed. --7FDnRloC5L6+fPHS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBEogoACgkQC3+MBN1Mb4gJpQCgikQwvjN4HXg07TWjOkzFI+BR lmMAnRla+KEAhhD//xLMrGUSoNMYkVmk =QbIO -----END PGP SIGNATURE----- --7FDnRloC5L6+fPHS--