amd64/171250: ldd32 cannot find some i386 libraries

Peter Jeremy peter at
Tue Sep 4 11:50:08 UTC 2012

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

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

 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 at> wr=
 > I have a symphathy to the idea that should translate well-k=
 > 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 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.
 Peter Jeremy
 Content-Type: application/pgp-signature
 Version: GnuPG v2.0.19 (FreeBSD)

More information about the freebsd-amd64 mailing list