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 1N0zZF-0006Sd-Ng for garchives@archives.gentoo.org; Thu, 22 Oct 2009 15:27:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C78DAE074F; Thu, 22 Oct 2009 15:27:08 +0000 (UTC) Received: from tommyserver.de (unknown [85.14.198.50]) by pigeon.gentoo.org (Postfix) with ESMTP id 74F2DE074F for ; Thu, 22 Oct 2009 15:27:08 +0000 (UTC) Received: from [192.168.178.22] (Q5d58.q.pppool.de [89.53.93.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tommyserver.de (Postfix) with ESMTPSA id 6AC764144FD for ; Thu, 22 Oct 2009 17:27:07 +0200 (CEST) Message-ID: <4AE079C2.6070904@gentoo.org> Date: Thu, 22 Oct 2009 17:26:58 +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> <200910121650.23974.vapier@gentoo.org> <4ADB626F.4050603@gentoo.org> <200910190308.58680.vapier@gentoo.org> In-Reply-To: <200910190308.58680.vapier@gentoo.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig76A9F8B3159F160E047EA338" X-Archives-Salt: 43f601ed-80bb-4c18-863d-7db2cb08ab3d X-Archives-Hash: 33937c7baaf7b72b03f461ebb028d738 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig76A9F8B3159F160E047EA338 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike Frysinger schrieb: > 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` >> Whats your suggestion? >=20 > the majority of the time, the compiler driver (i.e. `gcc`) should be us= ed for=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 p= ackages=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 nee= d funky=20 > behavior should still work as they will be calling $(tc-getLD) anyways.= Dropped $LD for now, seems to work fine for me. >=20 >>> - the -L paths to system dirs in LDFLAGS should not be there -- the >>> toolchain 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 >=20 > if things are failing, then we should look at gcc/binutils to make sure= they=20 > use the right default search paths when given -m32/-m64 I currently dont export any explicit LDFLAGS, but instead only save the v= alue at the end of each phase, seems to work fine for me. >=20 >>> 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). >> What do you mean here? If the diff between ABIs makes sense to install= >> seperate versions? >=20 > some packages (like glibc and linux-headers) already handle the multili= b=20 > situation. forcing the unnecessary Gentoo layer into the stack can eas= ily=20 > break things. For glibc, it is avoided since it has the "multilib" useflag. If this is = enabled, it indicates for me that the package does handle everything for itself, so multilib-portag= e does handle it as if it would be a normal package without multi-ABI request. Since linux-headers do also some special multilib handling, could you als= o add a "multilib" useflag for them? Currently i have an exception for them in my code to prevent pr= oblems for other packages. I assume that ever package not having a multilib useflag does not any mul= tilib-specific action. To check, if the header files differ per ABI, i save them for both ABIs, the= n diff them and create ABI-specific header files with a wrapper for all header files, that diffe= r. The rest is just installed as usual. >>> how do you differentiate between packages where multi ABIs make no se= nse >>> ? for example, most packages that dont install any libraries but just= >>> binaries. let's use the simple package app-text/tree. >> I dont differentiate. Currently i build for every ABI, if lib32 usefla= g is >> set and multilib useflag is not set. The idea behind it is to allow t= he >> installation of additional 32bit binaries, if requested. >=20 > that's is an immense waste of time. if we ran all the source phases fo= r a=20 > single ABI in one go, it should be easy to dynamically detect when a mu= ltilib=20 > multipass is necessary (by looking at library paths in $D). and for th= e odd=20 > package out, create a hook of some sort (EMULTIABI=3Dtrue) to force beh= avior. >=20 > 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) ? For packages with header files, i need to run all phases for both ABIs to= check, if the header files are ABI specific. So it would require a check for installed libs and installed header files= =2E And its more work since it requires both changes to the ebuild and emerge command. >=20 >>> a lot of this multilib code should probably continue to live in the t= ree >>> as it's a pretty big base of code to formalize that could do with fix= es >>> over time. i.e. we figure out that certain paths / define protection= s >>> dont work so well, so changing them to something else would require P= MS >>> 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. >> How do you want to do this? Require package managers to inherit some >> file/eclass? >=20 > considering this requires changes to the PM already, i dont see why not= =2E and=20 > it wouldnt really be an inherit in the current sense of the word. more= like a=20 > simple source. I am ok with this suggestion. >=20 >>> how are packages handled that can only be used via 1 ABI ? any of th= e >>> packages listed in the amd64 no-multilib package.mask for example. w= hile >>> these are mostly binary-only, this isnt a binary-specific issue. the= re >>> are a number of packages which only work on x86/ppc but could easily = work >>> in a multilib amd64/ppc64 as a 32bit binary (source code sucks, is >>> heavily asm, something else). >> 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 man= ager >> with multilib support, they could also depend on the useflag for the >> additional 32bit libs they need. >=20 > if it's a binary package, we know the ABI of it ahead of time. so if t= he=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 require= s). we=20 > dont want to rewrite every binary ebuild to include an explicit [foo] A= BI flag=20 > on each of its deps. This would require additional vars for multilib handling, which would req= uire inclusion in EAPI-3 or in a future EAPI, if the current process with EAPIs is continued. With the current implementation, i try to stay EAPI-independent, so the c= hanges can be implemented without having to wait for aproval of another EAPI. >=20 >>>> 2. Adding the internal lib32 useflag and usedeps with some workaroun= ds >>> what exactly does this "lib32" do ? naming USE flags according to >>> specific ABI implementations is a bad idea. you have to forget speci= al >>> casing anything to "lib32 vs lib64". amd64, while the most common, i= s >>> hardly extensible. we must handle multiple ABIs which easily might h= ave >>> the same bitsize. >> "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 a= ll >> dependencies too. I dont mind renaming it, if there is some other san= e >> naming for it. >=20 > 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= wants=20 > both x86 and x86_64 binaries by default. in the normal case, the PM ca= n then=20 > automatically resolve all dependencies as requiring all ABIs. if a bin= ary=20 > package is emerged, the ebuild itself declares the ABIs it provides, an= d then=20 > the PM only resolves the dependencies for the ABIs the package provides= =2E In general, this looks ok. As said above, i just want to prevent the mult= ilib-implementation from being delayed until another EAPI is created, aproved and implemented. --=20 Thomas Sachau Gentoo Linux Developer --------------enig76A9F8B3159F160E047EA338 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) iJwEAQEKAAYFAkrgeckACgkQG7kqcTWJkGe/zAP/UqIWRKQuPkDg1QcH0o6INmqB ZJnXV16iCJ28kvUTxuIQDpw7RQNLG86sMYLrDIwYdnkyGI9K2KigSN26WI4B47Mk GUFCCoZHOluN/4sTLzjOz3uAlHeOs6RlYjJd/ApJKswB8B+8atES2Wf/Ry4lH06U sLTb9mHgN+pM04lnJYg= =k2q7 -----END PGP SIGNATURE----- --------------enig76A9F8B3159F160E047EA338--