Date: Mon, 3 Sep 2012 12:30:19 GMT From: Konstantin Belousov <kostikbel@gmail.com> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries Message-ID: <201209031230.q83CUJkn069741@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/171250; it has been noted by GNATS. From: Konstantin Belousov <kostikbel@gmail.com> To: David Naylor <naylor.b.david@gmail.com> 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 > <snip/> > entry: 9 > d_tag: DT_RPATH > d_val: /usr/lib:/usr/local/lib > <snip/> > # 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209031230.q83CUJkn069741>