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 1MzmMT-0007qh-VL for garchives@archives.gentoo.org; Mon, 19 Oct 2009 07:08:58 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9E6A8E083E; Mon, 19 Oct 2009 07:08:56 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 5DB6BE083E for ; Mon, 19 Oct 2009 07:08:56 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 95DA1670AA for ; Mon, 19 Oct 2009 07:08:55 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay Date: Mon, 19 Oct 2009 03:08:57 -0400 User-Agent: KMail/1.12.2 (Linux/2.6.31.4; KDE/4.3.2; x86_64; ; ) References: <4A87FD91.20406@gentoo.org> <200910121650.23974.vapier@gentoo.org> <4ADB626F.4050603@gentoo.org> In-Reply-To: <4ADB626F.4050603@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="nextPart627971734.95qU3kNjnl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200910190308.58680.vapier@gentoo.org> X-Archives-Salt: 8d4cf953-723f-45b0-b80d-d0a9f6859ae9 X-Archives-Hash: 941e801e91d63b7661252e55c343e5d6 --nextPart627971734.95qU3kNjnl Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sunday 18 October 2009 14:46:07 Thomas Sachau wrote: > Mike Frysinger schrieb: > > another quick look at _setup_abi_env() looks like it needs work: > > - LD should not default to `ld` >=20 > Whats your suggestion? the majority of the time, the compiler driver (i.e. `gcc`) should be used f= or=20 linking. very few packages should invoke the linker directly. that is why= =20 currently the toolchain-func.eclass has tc-getLD return `ld` -- a few packa= ges=20 need it, but not most. if we're going to be forcing the setting of the LD = env=20 var all the time, then it needs to default to ${CC}. packages that need fu= nky=20 behavior should still work as they will be calling $(tc-getLD) anyways. > > - the -L paths to system dirs in LDFLAGS should not be there -- the > > toolchain can handle these just fine >=20 > Last time i tried without, some packages failed to compile, will test it > again to check, if its still needed if things are failing, then we should look at gcc/binutils to make sure the= y=20 use the right default search paths when given -m32/-m64 > > how do you control whether the multilib headers are needed ? it'll > > probably make sense in general, but there are def some packages where > > this will only get in the way (the toolchain ones). >=20 > What do you mean here? If the diff between ABIs makes sense to install > seperate versions? some packages (like glibc and linux-headers) already handle the multilib=20 situation. forcing the unnecessary Gentoo layer into the stack can easily= =20 break things. i imagine there are many other packages out there that use the same exact=20 header regardless of the ABI in use -- let the compiler figure out padding = of=20 structs and sizes of types. > > how do you differentiate between packages where multi ABIs make no sense > > ? for example, most packages that dont install any libraries but just > > binaries. let's use the simple package app-text/tree. >=20 > I dont differentiate. Currently i build for every ABI, if lib32 useflag is > set and multilib useflag is not set. The idea behind it is to allow the > installation of additional 32bit binaries, if requested. that's is an immense waste of time. if we ran all the source phases for a= =20 single ABI in one go, it should be easy to dynamically detect when a multil= ib=20 multipass is necessary (by looking at library paths in $D). and for the od= d=20 package out, create a hook of some sort (EMULTIABI=3Dtrue) to force behavio= r. i dont think there is any inherit reliance on running the multilib pass on= =20 each src step every time (other than that was easiest to implement) ? > > a lot of this multilib code should probably continue to live in the tree > > as it's a pretty big base of code to formalize that could do with fixes > > over time. i.e. we figure out that certain paths / define protections > > dont work so well, so changing them to something else would require PMS > > changing !? there has been talk before about pushing a lot of basic > > stuff to the tree so things dont have to be encoded in the PMS. >=20 > How do you want to do this? Require package managers to inherit some > file/eclass? considering this requires changes to the PM already, i dont see why not. a= nd=20 it wouldnt really be an inherit in the current sense of the word. more lik= e a=20 simple source. > > 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 > > these are mostly binary-only, this isnt a binary-specific issue. there > > are a number of packages which only work on x86/ppc but could easily wo= rk > > in a multilib amd64/ppc64 as a 32bit binary (source code sucks, is > > heavily asm, something else). >=20 > The binary-only ones are easy. Since they dont interact with the env, they > can be installed as usual. If they depend on a new enough package manager > with multilib support, they could also depend on the useflag for the > additional 32bit libs they need. if it's a binary package, we know the ABI of it ahead of time. so if the=20 package declared the binary ABI that it uses, then portage could handle the= =20 rest (making sure the deps are resolved against the ABI that it requires). = we=20 dont want to rewrite every binary ebuild to include an explicit [foo] ABI f= lag=20 on each of its deps. > >> 2. Adding the internal lib32 useflag and usedeps with some workarounds > > > > what exactly does this "lib32" do ? naming USE flags according to > > specific ABI implementations is a bad idea. you have to forget special > > casing anything to "lib32 vs lib64". amd64, while the most common, is > > hardly extensible. we must handle multiple ABIs which easily might have > > the same bitsize. >=20 > "lib32" is added to IUSE, you can enable as as every other useflag. > Internally, 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 some other sane > naming for it. i think every package will need tagging for each ABI, not just relative to = the=20 default one. so the profile on an amd64 multilib would declare that it wan= ts=20 both x86 and x86_64 binaries by default. in the normal case, the PM can th= en=20 automatically resolve all dependencies as requiring all ABIs. if a binary= =20 package is emerged, the ebuild itself declares the ABIs it provides, and th= en=20 the PM only resolves the dependencies for the ABIs the package provides. =2Dmike --nextPart627971734.95qU3kNjnl 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) iQIcBAABAgAGBQJK3BCKAAoJEEFjO5/oN/WBZoIP/RxFxp6HKr6NrKzmiWhP9CLe Kkoz75XsIlbhOF425PNbuc+ljAdPgCu7fllJcwYAR6tqPZUg2PPRyCvGmihR4GwH cYNHykheZExMuNStUqyCZ/oeRgn7clyuBys2Y526GDE9lzPpmHfUiGPoKq7PkX4n auFBFANIg8GNVrX0uU/IrnH1ewGnF76o/TEu+Nk9+6KNMorQgKPRZ1pglPGF9K4Q tJjJajrku7IoDS0bNg/H+KuiNr1db4WLRdV3gXJ52E99YSE1kY8Az7cb3KpmoJGb uJ3zXqStSwN++rquDE+4zuNOenuTC/2dy/z8bsG+JgqDqXKOCy4abSKHUi2QVeVX /Bp/BArCcGOYSdz+tV//X27cG6TNnP7zKVN1IlfDCymAFRQ+igOjd23Ab8HoRrTP bx2X+GMGJFV5MvQi/PnpS2TzKgYwpp52ziD8ifeYir9rDEhSBjTcVy9coiLQt/Sm +VhjBrEBlLGbzZogdIeovIlTkN3bba35+oua7nVM0UEqCN6F7a3EsT8lmwcdiNx/ MirttYq8GPC89G8Urdn43ieVuChD3WbRhBpbAGkZ+3k9EqBUQzbfHWO7yAKecEZG thcKq9necE47oWEYaujW/0bJbbAX1zsj/KC2oiZGWXpWJtwNh46Dx9jtA/sj0jn5 DBTKcHlnow4sXzbFG3QW =t0/R -----END PGP SIGNATURE----- --nextPart627971734.95qU3kNjnl--