Gentoo Archives: gentoo-dev

From: Mike Frysinger <vapier@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
Date: Mon, 26 Oct 2009 12:03:22
Message-Id: 200910260803.20448.vapier@gentoo.org
In Reply to: Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay by Thomas Sachau
On Thursday 22 October 2009 11:26:58 Thomas Sachau wrote:
> Mike Frysinger schrieb: > > On Sunday 18 October 2009 14:46:07 Thomas Sachau wrote: > >> Mike Frysinger schrieb: > >>> 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? > > > > some packages (like glibc and linux-headers) already handle the multilib > > situation. forcing the unnecessary Gentoo layer into the stack can > > easily 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-portage 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 also > add a "multilib" useflag for them? Currently i have an exception for them > in my code to prevent problems for other packages.
the linux-headers package doesnt have any multilib handling in them. the linux kernel itself takes care of installing proper headers for all ABIs (since they differ very little). it isnt possible to enable/disable this behavior afaik, so USE=multilib in the package makes no sense. perhaps cram all of these into a hidden USE expanded variable "EABI" ... but this is kind of a bad poor hack in face of creating a new dedicated variable to declare/control multilib settings.
> I assume that ever package not having a multilib useflag does not any > multilib-specific action. To check, if the header files differ per ABI, i > save them for both ABIs, then diff them and create ABI-specific header > files with a wrapper for all header files, that differ. The rest is just > installed as usual.
that should obviously work in general
> >>> 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. > >> > >> 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 single ABI in one go, it should be easy to dynamically detect when a > > multilib multipass is necessary (by looking at library paths in $D). and > > for the odd package out, create a hook of some sort (EMULTIABI=true) to > > force behavior. > > > > i dont think there is any inherit reliance on running the multilib pass > > on 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. > And its more work since it requires both changes to the ebuild and emerge > command.
my point is to skip multilib phases for a package that only installs executables. i dont think you need any changes to ebuilds to support this. if you run all src steps and then check for include files/libs in the $D dir, you know at that point whether you need to re-run the src steps for all ABIs.
> > if it's a binary package, we know the ABI of it ahead of time. so if the > > package declared the binary ABI that it uses, then portage could handle > > the rest (making sure the deps are resolved against the ABI that it > > requires). we dont want to rewrite every binary ebuild to include an > > explicit [foo] ABI flag on each of its deps. > > This would require additional vars for multilib handling, which would > require 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 > changes can be implemented without having to wait for aproval of another > EAPI.
this is an edge case that the rest of the implementation doesnt really need to rely on. in other words, we spec/prototype the right solution for this part for future EAPIs. now that i think about it more, i dont think explicit USE deps on these packages is really EAPI compliant either. for example, you cant change quake4-bin's depends from like "x11-libs/libXext" to "x11-libs/libXext[x86]" because that package doesnt have x86 in IUSE, nor does it make sense to add it. an EAPI change would be required anyways to handle funky source packages like wine where normally it's a 32bit binary, but it can be built as a 64bit binary via USE flags ... -mike

Attachments

File name MIME type
signature.asc application/pgp-signature