Re: [gentoo-dev] MULTI_ABI support addition to main tree portage

[Pacho Ramos]

El mié, 01-12-2010 a las 19:57 +0100, Thomas Sachau escribió:
> 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
>

Hello

I would like to know what is "blocking" this from landing main tree in
the "near" future, as I reviewed:

http://www.mail-archive.com/gentoo-dev@l.g.o/msg41737.html

and looks like there wasn't major problems (at least commented in this
thread)

Thanks a lot for the info :-)