From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1N0Pyc-0006LU-Th for garchives@archives.gentoo.org; Wed, 21 Oct 2009 01:26:59 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E20C4E07AF; Wed, 21 Oct 2009 01:26:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C0706E07AF for ; Wed, 21 Oct 2009 01:26:57 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 40F4E674ED for ; Wed, 21 Oct 2009 01:26:57 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: RFC: multilib and the compatibility to singlelib Date: Tue, 20 Oct 2009 21:27:14 -0400 User-Agent: KMail/1.12.2 (Linux/2.6.31.4; KDE/4.3.2; x86_64; ; ) References: <4ADDB5D5.30502@gentoo.org> <200910201345.17228.vapier@gentoo.org> <4ADE21F6.4000700@gentoo.org> In-Reply-To: <4ADE21F6.4000700@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1334152.v9ulGsUz5j"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910202127.15192.vapier@gentoo.org> X-Archives-Salt: 8d980dbb-139a-4efc-b4b7-0e496cfd4354 X-Archives-Hash: d04bef19c9287c5a630393505538cea8 --nextPart1334152.v9ulGsUz5j Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tuesday 20 October 2009 16:47:50 Jonathan Callen wrote: > Mike Frysinger wrote: > >> The problem was that Gentoo's early amd64 implementation predated this > >> standardization, and we had chosen the other way. While we've default= ed > >> to lib64 for 64-bit libs for years, it has never been considered > >> anything but experimental to break the lib --> lib64 link. AFAIK stab= le > >> baselayout still doesn't get its libdir usage consistent, putting files > >> in one but actually calling them using the other path, and boot breaks > >> in various frustrating ways if lib and lib64 are not the same director= y. > >> Openrc gets it better now, but I'm not sure it's all fixed either -- it > >> certainly wasn't last time I tried breaking the link. > > > > your "AFAIK" isnt useful. there are no open bugs about either version > > and people assume that it's doing the right thing. >=20 > Personally, I do have a ~amd64 Gentoo chroot with LIBDIR_x86=3D"lib". > There is only one place that I've found that it is still broken, namely > one line in toolchain.eclass (patch attached). I've been meaning to file > a bug for quite a while now, but never got around to it. off the top of my head, that doesnt really look like a correct fix. please= =20 open a bug with info on what you're actually doing. plus, your LIBDIR_x86 isnt really respected. there are places where=20 lib32/lib64 are hardcoded when modifying gcc/binutils (patch or sed). =2Dmike --nextPart1334152.v9ulGsUz5j Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iQIcBAABAgAGBQJK3mNzAAoJEEFjO5/oN/WBIgoP/RCjV+s5jCjgZOHSBnAtFoMR rk97uslk5bhIlz8KI2LfixcXRLxD1qZkldVQnDwjGBq2sl/r1TzI8d+4OCaZp2LJ DDyu6zSnayA6JW5VvCceLyUvSevbZ8wCPBDgT4COMRpbXWpr0nJpsVxuLBs0Hr/e uUFFONCS9accYcEaVDU79wAcfA54DNRQzlzoenN6CaAoWFRcAr5PiQOZfDzSMDxP dB1u1hqe4uqZc8pkgAFxaBuhkvMkqnjO0mZ2NuFxUlz9mHQg37T017KUYsVP3OX5 72rJR/C4qXMsXOhc0bpGIWf/lXsaFwYUmBLSgb4V0v/VznZyx1Tl/n8Bt55zkZqz rEaVcPcRYfH8BZLoaTGtcdtkcrnK3yPY+aAsR75Eqf1Len+8DYLKM5736ECaStwy WHFZJuh/tot0BtG44r9yYDGbtSu2qXuavSbwd1MFanpoUpACihKk1oF1zZvJQmhA vBM5ts5yDUS9AtAFdESb7KNPXj7ey1f/9Acp6NDKCwaszeSlECSrnL1f1JnJBYRJ hY9QN8PQ74vzD0A2ESvdCNbB3xLcjV6bBraUnct8/R8vhLtdnukT/F4kS0vXg23a h2YYjZhyz3sYS1duA3uyOZuq2PBQAw+s6Mki+Z5fWdOlufERdoDfxZNgQDIYxbo3 6X4QwA63q+GzYpSxxnVZ =BWQE -----END PGP SIGNATURE----- --nextPart1334152.v9ulGsUz5j--