From nobody@FreeBSD.org  Sun Sep  2 12:42:43 2012
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 6070B106564A
	for <freebsd-gnats-submit@FreeBSD.org>; Sun,  2 Sep 2012 12:42:43 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22])
	by mx1.freebsd.org (Postfix) with ESMTP id 4BB7E8FC0A
	for <freebsd-gnats-submit@FreeBSD.org>; Sun,  2 Sep 2012 12:42:43 +0000 (UTC)
Received: from red.freebsd.org (localhost [127.0.0.1])
	by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q82CghxD006817
	for <freebsd-gnats-submit@FreeBSD.org>; Sun, 2 Sep 2012 12:42:43 GMT
	(envelope-from nobody@red.freebsd.org)
Received: (from nobody@localhost)
	by red.freebsd.org (8.14.4/8.14.4/Submit) id q82Cghfe006816;
	Sun, 2 Sep 2012 12:42:43 GMT
	(envelope-from nobody)
Message-Id: <201209021242.q82Cghfe006816@red.freebsd.org>
Date: Sun, 2 Sep 2012 12:42:43 GMT
From: David Naylor <naylor.b.david@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ldd32 cannot find some i386 libraries
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         171250
>Category:       amd64
>Synopsis:       ldd32 cannot find some i386 libraries
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-amd64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Sep 02 12:50:06 UTC 2012
>Closed-Date:    
>Last-Modified:  Tue Sep  4 11:50:02 UTC 2012
>Originator:     David Naylor
>Release:        FreeBSD 9
>Organization:
>Environment:
FreeBSD dragon.dg 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Wed Aug 22 20:31:40 SAST 2012     root@dragon.dg:/tmp/home/freebsd9/src/sys/MODULAR  amd64
>Description:
ldd32 does not find libraries, yet ldconfig lists them as known.  

# ldconfig -32 -r | grep directories
        search directories: /usr/lib32:/usr/local/lib32:/usr/local/lib32/wine
# ldconfig -32 -r | grep 'lssl.6\|iconv.3'
        94:-lssl.6 => /usr/lib32/libssl.so.6
        124:-liconv.3 => /usr/local/lib32/libiconv.so.3
# ldd32 /usr/local/lib32/libcups.so.2 
/usr/local/lib32/libcups.so.2:
        libssl.so.6 => not found (0)
        libcrypto.so.6 => /usr/lib32/libcrypto.so.6 (0x281f4000)
        libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x28351000)
        libm.so.5 => /usr/lib32/libm.so.5 (0x28376000)
        libiconv.so.3 => not found (0)
        libz.so.6 => /usr/lib32/libz.so.6 (0x28390000)
        libthr.so.3 => /usr/lib32/libthr.so.3 (0x283a4000)
        libc.so.7 => /usr/lib32/libc.so.7 (0x2806c000)

>How-To-Repeat:
Install wine-fbsd64 from www.mediafire.com/wine_fbsd64 and follow instructions above.  
>Fix:
Explicitly include all library paths in LD_32_LIBRARY_PATH:
# env LD_32_LIBRARY_PATH=/usr/local/lib32:/usr/lib32 ldd32 /usr/local/lib32/libcups.so.2
/usr/local/lib32/libcups.so.2:
        libssl.so.6 => /usr/lib32/libssl.so.6 (0x281f4000)
        libcrypto.so.6 => /usr/lib32/libcrypto.so.6 (0x2823d000)
        libcrypt.so.5 => /usr/lib32/libcrypt.so.5 (0x2839a000)
        libm.so.5 => /usr/lib32/libm.so.5 (0x283bf000)
        libiconv.so.3 => /usr/local/lib32/libiconv.so.3 (0x28800000)
        libz.so.6 => /usr/lib32/libz.so.6 (0x283d9000)
        libthr.so.3 => /usr/lib32/libthr.so.3 (0x288f8000)
        libc.so.7 => /usr/lib32/libc.so.7 (0x2806c000)

>Release-Note:
>Audit-Trail:

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: 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/--

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

 --nextPart4535589.M6IlXmkH34
 Content-Type: Text/Plain;
   charset="us-ascii"
 Content-Transfer-Encoding: quoted-printable
 
 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.
 
 # 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
 =2E..
 
 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 prep=
 end=20
 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.
 
 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 behaviour.=
  =20
 
 Thanks for your quick reply.
 
 --nextPart4535589.M6IlXmkH34
 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)
 
 iEYEABECAAYFAlBEnCoACgkQUaaFgP9pFrJ+rACdFEfZkMQrm75Bs0B5+zY83c/4
 Y3MAoI62Ygvi/hl8hJ/44NOp2sNbw+5J
 =dpVu
 -----END PGP SIGNATURE-----
 
 --nextPart4535589.M6IlXmkH34--

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--

From: David Naylor <naylor.b.david@gmail.com>
To: Konstantin Belousov <kostikbel@gmail.com>
Cc: freebsd-gnats-submit@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--

From: Peter Jeremy <peter@rulingia.com>
To: Konstantin Belousov <kostikbel@gmail.com>
Cc: freebsd-gnats-submit@freebsd.org
Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries
Date: Tue, 4 Sep 2012 21:40:56 +1000

 --45Z9DzgjV8m4Oswq
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On 2012-Sep-03 12:30:19 +0000, Konstantin Belousov <kostikbel@gmail.com> wr=
 ote:
 > I have a symphathy to the idea that ld-elf32.so.1 should translate well-k=
 nown
 > pathes from DT_RPATH into their 32bit compat synonims. That is, /lib and
 > /usr/lib probably should be interpreted as /lib32 and /usr/lib32.
 
 That sounds like a good idea to me as well.
 
 > 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.
 
 My suggestion is that we define /usr/local/lib32 as a standard
 directory (and wire it into ld-elf32.so.1 in the same wap as /lib &
 /usr/lib) and extend /etc/libmap32.conf to define directory name
 mappings as well as dynamic object mappings to handle cases where
 LOCALBASE is not /usr/local and non-standard library directories.
 
 > This is closely related to non-existent multiarch support in ports, which
 > cannot even start happens without working cc -m32.
 
 I would disagree on this point.  There's no reason why we need a working
 "cc -m32" in order to pkg_add an i386 package on an amd64 system.  I
 notice there was some discussion regarding multi-arch ports on -current
 in late March.
 
 > I think your PR shall be postponed instead of being closed.
 
 Agreed.
 
 --=20
 Peter Jeremy
 
 --45Z9DzgjV8m4Oswq
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (FreeBSD)
 
 iEYEARECAAYFAlBF6MgACgkQ/opHv/APuId21ACgpl5kkWT6T5Lu7qSOJX8m+ZlU
 KvYAn2S1P4xrvZlZJBrxXwfJE6NUBQEl
 =+9H6
 -----END PGP SIGNATURE-----
 
 --45Z9DzgjV8m4Oswq--
>Unformatted:
