Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay

[Mike Frysinger]

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