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 1Mzaln-0005WW-88 for garchives@archives.gentoo.org; Sun, 18 Oct 2009 18:46:19 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 256FEE06FC; Sun, 18 Oct 2009 18:46:18 +0000 (UTC) Received: from tommyserver.de (unknown [85.14.198.50]) by pigeon.gentoo.org (Postfix) with ESMTP id BDF49E06FC for ; Sun, 18 Oct 2009 18:46:17 +0000 (UTC) Received: from [192.168.178.22] (Q2029.q.pppool.de [89.53.32.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tommyserver.de (Postfix) with ESMTPSA id A444126052 for ; Sun, 18 Oct 2009 20:46:17 +0200 (CEST) Message-ID: <4ADB626F.4050603@gentoo.org> Date: Sun, 18 Oct 2009 20:46:07 +0200 From: Thomas Sachau 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] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay References: <4A87FD91.20406@gentoo.org> <200910111716.22190.vapier@gentoo.org> <4AD3885C.3090403@gentoo.org> <200910121650.23974.vapier@gentoo.org> In-Reply-To: <200910121650.23974.vapier@gentoo.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig264CC359A1AE80215ED45F50" X-Archives-Salt: 013495a9-c595-4925-8fc3-743887456ada X-Archives-Hash: dfca70c2e1840d2ddf045479d210fa34 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig264CC359A1AE80215ED45F50 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike Frysinger schrieb: >=20 > another quick look at _setup_abi_env() looks like it needs work: > - LD should not default to `ld` Whats your suggestion? > - the -L paths to system dirs in LDFLAGS should not be there -- the to= olchain=20 > can handle these just fine Last time i tried without, some packages failed to compile, will test it = again to check, if its still needed > - missing CPPFLAGS handling Added > - see previous comments re-pkg-config Will have a look the next days > - you dont declare pyver local fixed > - the abi if check is uncommon syntax. "! [[ a =3D=3D b ]]" -> "[[ a = !=3D b ]]" fixed > how do you control whether the multilib headers are needed ? it'll pro= bably=20 > make sense in general, but there are def some packages where this will = only=20 > get in the way (the toolchain ones). What do you mean here? If the diff between ABIs makes sense to install se= perate versions? > how do you differentiate between packages where multi ABIs make no sens= e ? =20 > for example, most packages that dont install any libraries but just bin= aries. =20 > let's use the simple package app-text/tree. I dont differentiate. Currently i build for every ABI, if lib32 useflag i= s set and multilib useflag is not set. The idea behind it is to allow the installation of additional= 32bit binaries, if requested. > a lot of this multilib code should probably continue to live in the tre= e as=20 > it's a pretty big base of code to formalize that could do with fixes ov= er=20 > time. i.e. we figure out that certain paths / define protections dont = work so=20 > well, so changing them to something else would require PMS changing !? = there=20 > has been talk before about pushing a lot of basic stuff to the tree so = things=20 > dont have to be encoded in the PMS. How do you want to do this? Require package managers to inherit some file= /eclass? > how are packages handled that can only be used via 1 ABI ? any of the = > packages listed in the amd64 no-multilib package.mask for example. whi= le=20 > these are mostly binary-only, this isnt a binary-specific issue. there= are a=20 > number of packages which only work on x86/ppc but could easily work in = a=20 > multilib amd64/ppc64 as a 32bit binary (source code sucks, is heavily a= sm,=20 > something else). The binary-only ones are easy. Since they dont interact with the env, the= y can be installed as usual. If they depend on a new enough package manager with multilib suppo= rt, they could also depend on the useflag for the additional 32bit libs they need. >=20 >> 2. Adding the internal lib32 useflag and usedeps with some workarounds= >=20 > what exactly does this "lib32" do ? naming USE flags according to spec= ific=20 > ABI implementations is a bad idea. you have to forget special casing a= nything=20 > to "lib32 vs lib64". amd64, while the most common, is hardly extensibl= e. we=20 > must handle multiple ABIs which easily might have the same bitsize. "lib32" is added to IUSE, you can enable as as every other useflag. Inter= nally, portage does add [lib32?] usedeps to all dependencies. So if you enable the lib32 useflag,= portage will require this useflag for all dependencies too. I dont mind renaming it, if there is so= me other sane naming for it. --=20 Thomas Sachau Gentoo Linux Developer --------------enig264CC359A1AE80215ED45F50 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.13 (GNU/Linux) iJwEAQEKAAYFAkrbYnYACgkQG7kqcTWJkGd8TQP/cYAbTpHs5gWGIDyuH9KhpK0g OV9wXwFYWfBw9omyv3IiYJE0mz0STnUJJKCd5i+OS2DDInTlFfwX/YCAt2Vax5iN OKljL7L4XkroItGp8TDrYj6e17kuScYavR+fmyUCubYy5ch6N75vMReZySQ8d5G4 Xi3I5M80uJumlByBBM8= =OpOf -----END PGP SIGNATURE----- --------------enig264CC359A1AE80215ED45F50--