amd64/171250: ldd32 cannot find some i386 libraries
peter at rulingia.com
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 rulingia.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: Tue, 4 Sep 2012 21:40:56 +1000
Content-Type: text/plain; charset=us-ascii
On 2012-Sep-03 12:30:19 +0000, Konstantin Belousov <kostikbel at gmail.com> wr=
> I have a symphathy to the idea that ld-elf32.so.1 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 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
-----END PGP SIGNATURE-----
More information about the freebsd-amd64