The new revision does force cross-compile support for everyone and does not allow users to disable it. Additionally, it does leak a modified ABI var, which breaks cross-compile support of multilib-portage. Please have a look at other ebuilds (like sandbox-2.5) to see, how to implement multilib support without breaking multilib-portage. In addition, moving this behind the multilib USE flag allows an easy detection of internal cross-compile support and allows users to disable it (e.g. for amd64 no-multilib users).
Would like to understand what's going on: Wouldn't it make sense for multilib.eclass to cover 'use multilib'? Or for multilib-portage to preset ABI_ALLOW, which get_install_abis() does listen to? Are there cases where $MULTILIB_ABIS does not contain $ABI?
(In reply to comment #1) > Or for multilib-portage to preset MULTILIB_ABIS=$ABI (and DEFAULT_ABI=$ABI) ? Anyway: fixed.
What you did and do in the ebuild is something similar to what multilib-portage does, but you redefine variables, which are used by multilib-portage (like the ABI variable). Currently, libaio does work with USE=multilib, since then the ebuild does the multilib setup itself and multilib-portage does not touch it, but it fails to work with USE=-multilib and multilib-portage. The reason is simple: in src_install, you do things conditionally based on "is_final_abi" function. But this does not work with multilib-portage, since it does a full run for one ABI and then another full run for the next ABI. So for ABI=amd64, it works as expected, since docs and manpages are installed, so the later rm can remove the manpages again. But for ABI=x86, the manpages are not installed, so the removal of manpages does fail. Beside that, i dont know, why the ebuild does first install manpages and then removes them afterwards. Anyway, the solution is simple: drop the condition, always dodoc and doman and drop the removal of the header, everything works fine for me without those lines. To show you the lines of the ebuild i tested: <unchanged stuff> emake_libaio install DESTDIR="${D}" doman man/* dodoc ChangeLog TODO # move crap to / for multipath-tools #325355 gen_usr_ldscript -a aio <unchanged stuff>
(In reply to comment #3) > What you did and do in the ebuild is something similar to what > multilib-portage does, but you redefine variables, which are used by > multilib-portage (like the ABI variable). How else if not via ABI to have things like "get_libdir" to return the abi-specific value? > The reason is simple: in src_install, you do things conditionally based on > "is_final_abi" function. But this does not work with multilib-portage, since > it does a full run for one ABI and then another full run for the next ABI. > > So for ABI=amd64, it works as expected, since docs and manpages are > installed, so the later rm can remove the manpages again. But for ABI=x86, > the manpages are not installed, so the removal of manpages does fail. Ohw, indeed: The removal of manpages is done in src_prepare now. But I'd still prefer to drop the headerfiles for the non-final abi: Does this break with multilib-portage too? > Beside that, i dont know, why the ebuild does first install manpages and > then removes them afterwards. Only those manpages provided by sys-apps/man-pages are removed. > Anyway, the solution is simple: drop the condition, always dodoc and doman > and drop the removal of the header, everything works fine for me without > those lines. I'd prefer to provide non-binaries (docs, headers) upon is_final_abi: Is this a problem for multilib-portage in general?
(In reply to comment #4) > (In reply to comment #3) > > What you did and do in the ebuild is something similar to what > > multilib-portage does, but you redefine variables, which are used by > > multilib-portage (like the ABI variable). > > How else if not via ABI to have things like "get_libdir" to return the > abi-specific value? I just pointed out the original source of issue. And since that ABI var is changed, when you do the multilib handling in the ebuild, this needs to be done either by the ebuild (telling with the multilib USE flag to multilib-portage, that the ebuild does the work) or by multilib-portage. Anything else resulting in mixed handling of multilib will likely cause issues. > > > The reason is simple: in src_install, you do things conditionally based on > > "is_final_abi" function. But this does not work with multilib-portage, since > > it does a full run for one ABI and then another full run for the next ABI. > > > > So for ABI=amd64, it works as expected, since docs and manpages are > > installed, so the later rm can remove the manpages again. But for ABI=x86, > > the manpages are not installed, so the removal of manpages does fail. > > Ohw, indeed: The removal of manpages is done in src_prepare now. > > But I'd still prefer to drop the headerfiles for the non-final abi: > Does this break with multilib-portage too? > > > Beside that, i dont know, why the ebuild does first install manpages and > > then removes them afterwards. > > Only those manpages provided by sys-apps/man-pages are removed. > > > Anyway, the solution is simple: drop the condition, always dodoc and doman > > and drop the removal of the header, everything works fine for me without > > those lines. > > I'd prefer to provide non-binaries (docs, headers) upon is_final_abi: > Is this a problem for multilib-portage in general? is_final_abi does in the end just check, if $ABI == $DEFAULT_ABI So whenever someone only wants to cross-compile for x86 (with multilib-portage), non-binaries will be missing. Why do you want to restrict those installations to is_final_abi anyway? They just overwrite the existing files, so do not even cost extra filespace.
(In reply to comment #5) > > I'd prefer to provide non-binaries (docs, headers) upon is_final_abi: > > Is this a problem for multilib-portage in general? > > is_final_abi does in the end just check, if $ABI == $DEFAULT_ABI > > So whenever someone only wants to cross-compile for x86 (with > multilib-portage), non-binaries will be missing. "cross-compiling" has multiple meanings it seems, especially when mixing with "multilib": Do you mean cross-compiling to a pure-x86 ROOT? Here both DEFAULT_ABI and ABI should be x86. Or compile for the x86 part only in an amd64-multilib setup? Ok, I take this as the argument to install non-binaries always. > Why do you want to restrict those installations to is_final_abi anyway? They > just overwrite the existing files, so do not even cost extra filespace. Its not about filespace, its also about avoiding duplicate copy-operations, as well as what is the Right Thing (tm).
(In reply to comment #6) > Or compile for the x86 part only in an amd64-multilib setup? > Ok, I take this as the argument to install non-binaries always. Fixed.
(In reply to comment #6) > (In reply to comment #5) > > > I'd prefer to provide non-binaries (docs, headers) upon is_final_abi: > > > Is this a problem for multilib-portage in general? > > > > is_final_abi does in the end just check, if $ABI == $DEFAULT_ABI > > > > So whenever someone only wants to cross-compile for x86 (with > > multilib-portage), non-binaries will be missing. > > "cross-compiling" has multiple meanings it seems, especially when mixing > with "multilib": > > Do you mean cross-compiling to a pure-x86 ROOT? > Here both DEFAULT_ABI and ABI should be x86. > > Or compile for the x86 part only in an amd64-multilib setup? > Ok, I take this as the argument to install non-binaries always. "cross-compiling" and "multilib" should in this case both mean compiling for another ABI, e.g. compiling for x86 on an amd64 setup. > > > Why do you want to restrict those installations to is_final_abi anyway? They > > just overwrite the existing files, so do not even cost extra filespace. > > Its not about filespace, its also about avoiding duplicate copy-operations, > as well as what is the Right Thing (tm). At least in some cases, files differ, always for libs, often for binaries and sometimes even for headers. Multilib-portage does now check, if the files for x86 and amd64 differ and does install them seperatly together with a wrapper, which selects the right file based on current ABI. So beside the missing files, when one only compiles for x86 on an amd64 setup, not installing for none-default ABIs would prevent those checks and preparation of ABI-specific files.
