From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 83E3A1385AD for ; Sun, 20 Jan 2013 23:06:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2E09A21C0B4; Sun, 20 Jan 2013 23:06:09 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0B5BB21C094 for ; Sun, 20 Jan 2013 23:06:07 +0000 (UTC) Received: from [192.168.178.20] (p548D2CC0.dip.t-dialin.net [84.141.44.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: tommy) by smtp.gentoo.org (Postfix) with ESMTPSA id 8331933D777 for ; Sun, 20 Jan 2013 23:06:06 +0000 (UTC) Message-ID: <50FC7857.5080002@gentoo.org> Date: Mon, 21 Jan 2013 00:05:59 +0100 From: Thomas Sachau User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0 SeaMonkey/2.14.1 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib References: <20130120201131.5afcbf48@pomiocik.lan> <20130121010556.27f8fac6@sf> In-Reply-To: <20130121010556.27f8fac6@sf> X-Enigmail-Version: 1.4.6 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig57C9C40D2A72DAAFD092180D" X-Archives-Salt: a8851b29-fe41-4242-aa3a-430ab65db1ae X-Archives-Hash: 9213b9dd263cf6f04726359b4191011a This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig57C9C40D2A72DAAFD092180D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sergei Trofimovich schrieb: > On Sun, 20 Jan 2013 20:11:31 +0100 > Micha=C5=82 G=C3=B3rny wrote: >=20 >> Hello, >> >> There is a fair interest in multilib and while still early, it would b= e >> a good moment to decide on how USE flags to use for it. >> >> The current attempts are mostly using USE=3Dmultilib which is not real= ly >> expressive and poor. What I would go for is a clear variable specifyin= g >> which targets package is built for. >=20 > You just need to add 'ABI' and 'MULTILIB_ABIS' to > "emerge --info ${pkg}" output. >=20 > Do you plan to keep precise depends for packages? > like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32. >=20 > What to do if someone builds a package only with non-default ABI? > (it means installed package does not quite work for default ABI) >=20 > like on ABI=3Damd64 media-libs/glu[ABI=3Dx32] could not be used by > any of ABI=3Damd64 users. >=20 > In order to track such depends precisely you would need to add > ABI flags to each revdep recursively. It's quite invasive. Is it worth > the effort? >=20 > Currently USE=3Dmultilib means 'build for all toolchain-supported' ABIs= =2E > It looks clean and short. >=20 >> This raises the following questions: >> >> 1) do we want the default ABI to be switchable? > It already is via /etc/portage/env per-package. > Or via profile globally. arch/amd64/make.defaults: > MULTILIB_ABIS=3D"amd64 x86" = =20 > DEFAULT_ABI=3D"amd64" >=20 > crossdev allows bootstrapping with any random default > ABI out there as one-liner: > crossdev -A 'x32 amd64' x86_64-unknown-linux-gnu. >=20 >> 2) do we want irrelevant ABIs to be visible to emerge users? >> >> By 2) I mean: do we want the users to see stuff like: >> >> MULTILIB_ABIS=3D"amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) >> (-ppc64_abi2) (-ppc64_abi3) ..." >=20 > Would adding irrelevant ABIs trigger rebuilds on world update? >=20 > Do you intermingle gentoo's $ARCH and ABI? > How many ABI vars do you expect to see for simple "common" cases? >=20 > x86_64-pc-linux-gnu-gcc -m32 (host ARCH=3Damd64) > x86_64-pc-linux-gnu-gcc -m64 (host ARCH=3Damd64) > x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=3Damd64) > i686-pc-linux-gnu-gcc -m32 (host ARCH=3Dx86) > i686-pc-linux-gnu-gcc -m64 (host ARCH=3Dx86) > i686-pc-linux-gnu-gcc -mx32 (host ARCH=3Dx86) >=20 > 3 or 6? >=20 > Looks like insane amount of metadata growth for each > plagued package. >=20 >> or just the relevant part. >> >> To be honest, I don't know if there's other way to hide USE flags than= >> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split >> the flags per-arch, i.e. have: >> >> MULTILIB_AMD64=3D"abi1 abi2 abi3" >> MULTILIB_PPC64=3D"abi1 abi2 abi3" >> >> with appropriate USE_EXPAND_HIDDEN set by profiles. >=20 > Having direct support in portage's core might reduce amount of > user-visible/storable metadata in main tree. No slightest idea > how it would look like though. >=20 Support for cross-compiling packages for toolchain-supported ABIs already exists and works for some years in multilib-portage (code in the multilib branch of portage git repo, ebuild in the multilib-portage overlay with very basic setup instructions in the doc dir of the overlay and the #gentoo-multilib-overlay channel in freenode for questions). --=20 Thomas Sachau Gentoo Linux Developer --------------enig57C9C40D2A72DAAFD092180D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iJwEAQECAAYFAlD8eFgACgkQG7kqcTWJkGdwMAQAhksT4wXG9kL7ICWGIo5Ow/Lb hkwj5zJ4M/dVGxU5K0vzpPhLC/Zm7LqDx/2m+KXL8i9RZTdloiRlvnxft4Y4ZkBW VEKvzfdgkslwthUaRQCz6lmkrlJtn+jnCQcEHV6bnUCQ7GzDDJRzN0KIMWuN3rLM wejAFKvKhUlmvD72+UA= =Hwjz -----END PGP SIGNATURE----- --------------enig57C9C40D2A72DAAFD092180D--