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 1NTBmo-0002gg-SV for garchives@archives.gentoo.org; Fri, 08 Jan 2010 10:09:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 762B1E0950 for ; Fri, 8 Jan 2010 10:09:42 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 38D41E0686 for ; Fri, 8 Jan 2010 09:09:39 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id BC64567DAD for ; Fri, 8 Jan 2010 09:09:38 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date Date: Fri, 8 Jan 2010 04:09:36 -0500 User-Agent: KMail/1.12.4 (Linux/2.6.32.2; KDE/4.3.4; x86_64; ; ) References: <7c612fc60912150854k608270cag61c533542075f5bf@mail.gmail.com> <20091226102500.GK1452@gentoo.org> <4B360C6A.10602@gentoo.org> In-Reply-To: <4B360C6A.10602@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="nextPart9572426.u1H4SmaCtk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001080409.37320.vapier@gentoo.org> X-Archives-Salt: c3c62d22-b5f8-42ce-9521-dc8ff59c8e1d X-Archives-Hash: 96c841f9fdd29e5db91a197dfc8e8627 --nextPart9572426.u1H4SmaCtk Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Saturday 26 December 2009 08:15:22 Thomas Sachau wrote: > On 12/26/2009 11:25 AM, Fabian Groffen wrote: > > This is about what I understood. Now here I have some questions that > > may or may not be relevant. > > > > What triggers a multilib build? Is it unconditional, or can it be > > turned on/off per package? How does Portage resolve/verify that a > > library is built for the right ABI in that case? >=20 > Currently multilib-portage does add a USE flag called "lib32". If you > enable it, you will get the cross-compile, else just the normal install. > In addition this flag is internally used like an EAPI-2 usedep, so it wi= ll > require the dependencies to be built for all ABIs too. this is something that needs to be fixed per the earlier discussion > > Unpacking sources many times feels like a terrible waste to me, > > especially for things like GCC. If we would just start building outside > > of the workdir (sources) into a separate builddir, wouldn't that just > > be much cleaner and a nice EAPI feature? >=20 > That might be an extra step, once the basic implementation works, but you > will have to adjust some things, since e.g. cmake-utils eclass does > already something like that, maybe others do it too, so you would have to > change those ebuilds/eclasses or add exceptions or extra rules to portage > for those. Some packages like gcc or glibc already do this multilib-stuff > internally with the multilib USE flag, so you currently wont get any > better experience for them. indeed ... it'd be nice if we only ran src_unpack() once, but there are=20 packages in EAPI0 that modify the source based on ABI/build flags. the onl= y=20 safe way is to always run the src_unpack() multiple times. once this implementation settles on top of EAPI{0..3}, we can look at EAPI4= +=20 to optimize the flow. > > Since you make each compilation multiple times, you also obtain a fully > > identical installation of the same package. How do you deal with that? > > Do you have /usr/bin{64,32} directories for example too? If you only > > keep libs (found by a scanelf scan or something), how do you know what's > > relevant. Alternatively, if you build the full application anyway, > > isn't it a waste to throw away the result? You could see multilib also > > as two (unrelated) trees, such as e.g. a Gentoo Prefix installation. > > A nasty one: how to deal with libs that actually contain hardcoded paths > > to configuration from e.g. /etc or /var in your implementation? >=20 > Currently i only work and test with amd64-ARCH, so with x86 and amd86 ABI. > For those, the lib-part is easy since the crosscompile does install the > libs into /usr/lib32 while the 64bit ones go into /usr/lib64. The headers > for both ABIs are diffed and different ones are preserved, the rest is > isntalled as usual. For binaries, normally only the one for the > DEFAULT_ABI, so in this case the 64bit one, will be preserved. But you c= an > tell multilib-portage to preserve the 32bit binaries. In that case, the > binaries will be called $binary-$ABI and a symlink $binary to a wrapper > created, which calls the real binary depending on the current ABI. can you guys think of a package where the bindirs differ and/or we care ? =2Dmike --nextPart9572426.u1H4SmaCtk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAABAgAGBQJLRvZRAAoJEEFjO5/oN/WBlNYQAI//NyNCbe20zz68MqJ4Ofoy QBcRNRJHOZ2pX400ZuKg1T7+A+qADuMJlWQl4ME9lJHDMR87wT333BwLCDlVACm6 2xOu5MEw1Fn0rpcdmTye9/HLEWv3c8VyeyR/IUu8TnkF5nLNFwCCsTqZ0NJBvfa7 QVyyyg15tIeVU/o08Il8JWaCkRrjcPVSZjBJuU6UGI2R7CD8+y5KILRoR4uCyQBW Dat7vepvJu1NzaaqnI0hwRIYudL058N6D9LVzPt/FHcZpkAemw7/CSVvIjXbAnbe IltQ+2kuH577XOxp+oLNKCS/RcAv1cQDcSmT9qCCTf4j62V6WB7Z0tQ4moZf5IgQ Ur6WaMA1Ck5jJ7LF0z13z6z5VtQuLnE5yb87jw9BQNZ9vQ60igv5lHvYVNGu3ws/ naCMYewx4zOJoUHNxf1DpGDOx9SVsNwCfRUfEBg9fSnhvweYuRGkjNou8lmsM7uM G+gwWEpXfAPLi0g/AW/cAIrwxAE7wiCH6SmS4pYMWdyYFFmadp1w7R+Lkh8RrwkV 4ua+46s1YNeEOFJASBSJ3PGNyUeG4ScxpS/onXufQUNCtIcwpodeNM+CpR8nF8qx rD62F3A2KxrSpteoZRIZ039wBTihFlxz22RpYL6A1LkwymeHl+wXqsjYxRy9aNTg Pf0dMV/DqcD+Jxd/mjuN =144h -----END PGP SIGNATURE----- --nextPart9572426.u1H4SmaCtk--