amd64/171250: ldd32 cannot find some i386 libraries

[David Naylor]

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

From: David Naylor <naylor.b.david at gmail.com>
To: Konstantin Belousov <kostikbel at gmail.com>
Cc: freebsd-gnats-submit at freebsd.org
Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries
Date: Mon, 3 Sep 2012 14:39:32 +0200

 --nextPart12163879.7IcdIZSAUr
 Content-Type: Text/Plain;
   charset="us-ascii"
 Content-Transfer-Encoding: quoted-printable
 
 On Monday, 3 September 2012 14:26:50 Konstantin Belousov wrote:
 > 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
 > >=20
 > >         d_tag: DT_RPATH
 > >         d_val: /usr/lib:/usr/local/lib
 > >=20
 > > <snip/>
 > > # elfdump -a libcups.so.2 | grep DT_RUNPATH
 > > ...
 > >=20
 > > As you suspected the paths are hardcoded.  However, since this is a 32b=
 it
 > > library (and compiled in a i386 chroot) on a 64bit system I would have
 > > expected the dynamic linker to translate /usr/lib to /usr/lib32, or to
 > > prepend it.
 > >=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=
 =2E=20
 > > I'm happy to continue using LD_32_LIBRARY_PATH to enduce the correct
 > > behaviour.
 > >=20
 > > Thanks for your quick reply.
 >=20
 > I have a symphathy to the idea that ld-elf32.so.1 should translate
 > well-known pathes from DT_RPATH into their 32bit compat synonims. That is,
 > /lib and /usr/lib probably should be interpreted as /lib32 and /usr/lib32.
 
 =46YI, I do not have a /lib32 on my system, only /usr/lib32. =20
 
 Would not a reasonable first step be to simple append /usr/lib32 to the sea=
 rch=20
 path, thus if there is reason to find a valid library in the normal path it=
 =20
 would be discovered first, but fall back to the compat directory if needed.=
  =20
 
 > 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.
 
 The append method above, doing s/lib/lib32/, may be an acceptable attempt. =
 =20
 The way I current do it with wine-fbsd64 packages is to create a shell scri=
 pt=20
 that added the non-default paths to LD_32_LIBRARY_PATH and `exec` to the=20
 binaries under bin32. =20
 
 > This is closely related to non-existent multiarch support in ports, which
 > cannot even start happens without working cc -m32.
 >=20
 > I think your PR shall be postponed instead of being closed.
 
 Happy bug hunting...
 
 --nextPart12163879.7IcdIZSAUr
 Content-Type: application/pgp-signature; name=signature.asc 
 Content-Description: This is a digitally signed message part.
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEABECAAYFAlBEpQcACgkQUaaFgP9pFrJW2QCfTk3jvWoQ/9y9BOHyQdYbaNr4
 v1sAniHxlOqDGJWEYxwsOuiQMgpb4eUg
 =D25V
 -----END PGP SIGNATURE-----
 
 --nextPart12163879.7IcdIZSAUr--