amd64/171250: ldd32 cannot find some i386 libraries

[Konstantin Belousov]

The following reply was made to PR amd64/171250; it has been noted by GNATS.

From: Konstantin Belousov <kostikbel at gmail.com>
To: David Naylor <naylor.b.david at gmail.com>
Cc: freebsd-gnats-submit at freebsd.org
Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries
Date: Sun, 2 Sep 2012 18:57:55 +0300

 --7HqTdBsuSOA5h1B/
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 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
 >=20
 > # ldconfig -32 -r | grep directories
 >         search directories: /usr/lib32:/usr/local/lib32:/usr/local/lib32/=
 wine
 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.
 
 > # ldconfig -32 -r | grep 'lssl.6\|iconv.3'
 >         94:-lssl.6 =3D> /usr/lib32/libssl.so.6
 >         124:-liconv.3 =3D> /usr/local/lib32/libiconv.so.3
 > # ldd32 /usr/local/lib32/libcups.so.2=20
 > /usr/local/lib32/libcups.so.2:
 >         libssl.so.6 =3D> not found (0)
 If DT_R*PATH specified native directory, dynamic linker found the
 libssl.so.6 which is for the wrong architecture, and claimed the
 dependency not satisfied.
 
 >         libcrypto.so.6 =3D> /usr/lib32/libcrypto.so.6 (0x281f4000)
 >         libcrypt.so.5 =3D> /usr/lib32/libcrypt.so.5 (0x28351000)
 >         libm.so.5 =3D> /usr/lib32/libm.so.5 (0x28376000)
 >         libiconv.so.3 =3D> not found (0)
 >         libz.so.6 =3D> /usr/lib32/libz.so.6 (0x28390000)
 >         libthr.so.3 =3D> /usr/lib32/libthr.so.3 (0x283a4000)
 >         libc.so.7 =3D> /usr/lib32/libc.so.7 (0x2806c000)
 >=20
 > >How-To-Repeat:
 > Install wine-fbsd64 from www.mediafire.com/wine_fbsd64 and follow instruc=
 tions above. =20
 > >Fix:
 > Explicitly include all library paths in LD_32_LIBRARY_PATH:
 > # env LD_32_LIBRARY_PATH=3D/usr/local/lib32:/usr/lib32 ldd32 /usr/local/l=
 ib32/libcups.so.2
 > /usr/local/lib32/libcups.so.2:
 >         libssl.so.6 =3D> /usr/lib32/libssl.so.6 (0x281f4000)
 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.
 
 --7HqTdBsuSOA5h1B/
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.12 (FreeBSD)
 
 iEYEARECAAYFAlBDggMACgkQC3+MBN1Mb4gRgQCgyZN3to7Wz8sxTy0wdXTpZ0bQ
 tUcAn3KTXVYq7kC8tVDD99Qs4DS4e8n4
 =WPKe
 -----END PGP SIGNATURE-----
 
 --7HqTdBsuSOA5h1B/--