Hi,

i have already written about this some months ago and updated the code in relation to the comments
especially from vapier.

Basicly, it does now first set abi-specific vars (like CC, CFLAGS and others (setup_abi_env function
in bin/auto-multilib.sh contains the full list), then does build the package as usual. If additional
ABIs are requested, it checks after src_install, if there are possible ABI-specific files (libs,
headers or, if requested for every ABI, also binaries). If those are found, the image dir is moved
away and a new run is started, where again at start abic-specific vars are set and then the complete
src* phases are run. Once all requested ABIs are done, the image dirs are merged into the final
image dir. The following pkg_* phases are each running for every ABI.
Currently, only different libs and headers are installed by default, binaries will be the ones from
the default ABI, unless you tell portage to install binaries for all requested ABIs, in which case a
wrapper will select the ABI-specific binary depending on the environment.
The current implementation uses a USE-dep like way internally to satisfy the needed dependencies, so
that e.g. 32bit libs on a 64bit platform get their required dependencies built with 32bit libs
installed. For the rare case, where the crosscompile does fail and there is only a need for the
binary and no linking against the libs, i have also a var, which disables this auto-dependency
calculation for specified packages.

For the user interface, portage shows a USE_EXPANDed var, which contains the avaidable ABIs, as an
example for "emerge -pv media-libs/jpeg":

[ebuild   R   ] media-libs/jpeg-8b  USE="-static-libs" MULTILIB_ABI="amd64 x86"

Those ABIs can be handled like USE flags, in this case, they are "multilib_abi_amd64" and
"multilib_abi_x86", so you can use those USE flags to enable/disable specific possible ABIs either
globally or per package.

The basic implementation can be used without changing main tree ebuilds or eclasses, but e.g. for
the replacement of emul-* libs, this will require EAPI-support for ABI-specific USE-deps for
binary-only packages or packages like wine.

I would first like to see, if there are any bigger concerns especially with the implementation and
how it is supposed to work.

If there are no such concerns or if they have been resolved, i would like to request some help for
the documentation and PMS-patch related work.

For install instructions, please have a look at [1], the code can be found in the multilib branch of
portage git repo at [2].

While i did not yet get to the implementation of it, i would also like to propose something similiar
for languages (like python, ruby or others), so that the basic parts are inside the PM and we can
drop the different ways of implementation and allow users a much more fine-grained control on a per
package base (in relation to the current way python eclass based very complex implementation works).

[1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib/doc
[2]: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=shortlog;h=refs/heads/multilib

-- 
Thomas Sachau

Gentoo Linux Developer