Date: Tue, 4 Sep 2012 11:50:07 GMT From: Peter Jeremy <peter@rulingia.com> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/171250: ldd32 cannot find some i386 libraries Message-ID: <201209041150.q84Bo7CZ087768@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/171250; it has been noted by GNATS. 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201209041150.q84Bo7CZ087768>