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 1N0JFM-0000Oq-Sa for garchives@archives.gentoo.org; Tue, 20 Oct 2009 18:15:49 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7E596E06F4; Tue, 20 Oct 2009 18:15:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 3B55EE06F4 for ; Tue, 20 Oct 2009 18:15:47 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id AE11F67E02 for ; Tue, 20 Oct 2009 18:15:46 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: multilib and the compatibility to singlelib Date: Tue, 20 Oct 2009 14:16:01 -0400 User-Agent: KMail/1.12.2 (Linux/2.6.31.4; KDE/4.3.2; x86_64; ; ) References: <4ADDB5D5.30502@gentoo.org> In-Reply-To: <4ADDB5D5.30502@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="nextPart3120839.QuTyFKBeDl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910201416.02169.vapier@gentoo.org> X-Archives-Salt: 020b1ceb-bf15-47d7-bd44-667690fde11d X-Archives-Hash: e448243668bcfbb145abafabce0015ac --nextPart3120839.QuTyFKBeDl Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tuesday 20 October 2009 09:06:29 Michael Haubenwallner wrote: > As I'm building the toolchain myself too, I configure it with the > 32bit host triplet on each platform, usually disabling multilib. this doesnt make any sense to me > This simply works for ppc-aix, hppa-hpux, ia64-hpux, sparc-solaris, > x86-solaris, even if the underlying OS/kernel is 64bit. > It isn't even necessary to explicitly use --{build,host} at all, > as config.guess tells the 32bit triplet on these platforms. > Additionally, even their default compiler output is 32bit. >=20 > But Linux "is not Unix": you're right, so i'm not terribly concerned with compatibility with non-Lin= ux=20 systems. comparing the native Gentoo/Linux multilib setup to another Linux= =20 multilib setup is the only useful comparison. > Configuring both binutils and gcc needs to be done with: > $ CC=3D"gcc -m32" /path/to/configure --{build,host}=3Di686-pc-linux-gnu= ... > This works on 64bit RHEL as well as on 64bit SLES (both have 32bit in /li= b, > 64bit in /lib64, no /lib32), but breaks on amd64+multilib Gentoo Linux. >=20 > Problem is that, as x86-linux isn't a multilib target, both ld and gcc > search for 32bit libs&objects in /usr/lib:/lib, as they don't know about > /usr/lib32:/lib32. The error when bootstrapping gcc is: > /usr/lib/crti.o: file not recognized: File format not recognized i dont get it. why does the i686-pc-linux-gnu toolchain target matter on a= n=20 amd64 multilib system ? the native x86_64-pc-linux-gnu toolchain should=20 already do the right thing when given -m32. > While it is possible to patch binutils[1] and gcc[2] to search in > /usr/lib32:/lib32 even with this otherways non-multilib target, > it doesn't feel like the "right thing" to enable multilib for > just one multilib option. >=20 > Isn't the intention of multilib to have a new (64bit) system > be compatible with the corresponding old (32bit) system? your description of "compatible" is pretty vague. ignoring /lib -> /lib64= =20 symlink (which shouldnt matter to any binaries), i'm not aware of any=20 differences off the top of my head. =2Dmike --nextPart3120839.QuTyFKBeDl 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) iQIcBAABAgAGBQJK3f5iAAoJEEFjO5/oN/WBSCsQALZtxFx/UAdqVpuuaOBtYAcU 7WNT0fpR1aD2ihfN5RmO9SlMcmgt7sumRgi8Xkxs03j/8T1OUQyHMs4+6y24Y4KP be1Q/8IWOa6eUBFEcpXLKRqlJzWsoExtkcVkm5OvJWRrxYJJ1nI54rJ/FYlG8xKH tQW/fQ9A1Zjm5MWgr8vURX6ADq8lu5VklGANiHE21cQTgJl5t9p/L4hdFEAEUSSK fhpdu48V/5kdsryXICrEW9we3kRKp/Nx/12vXIRlKKIxPaZ9ccUO1uNJ7yDnHJLW wDrJQNghhymgVazlmxBOxdtghLO9z/gpmBbgfsjnf55oYOA7m79kE6YgEq8vT1VX 1jCFPnIdFBHKrCcQczDttdW1BWIQr6+6080e7spft4CsVmOdmN1axGDCMKf+ouAV CAiMlZeg6gh6cwGYIMlXYw2Sc9MGGaxsVbiz4OuF0cAOaHaUrrjAx2jmPdWoREZZ AEuqNHXuiPdEz0d5VPqdKt0GrFsuJx0Od0YbbJu4uL/jQDZIt/Sfkrz+FhTAF0kM iYKKcRzlON+UftTKdLTcyiill43ONPgMePguw4WhhuozhLBCgroTx5QLWbQaZXLi hdMOzEnoPBTfHL25G8o8CtT0G8NmfBPLwRFLODWe6WNhZIABDjsEFxQhMzmY8IqU ZCgnRBzZfUw0wYoUR+t+ =eH+Q -----END PGP SIGNATURE----- --nextPart3120839.QuTyFKBeDl--