On Sun, Jul 1, 2012 at 7:29 AM, Thomas Sachau <to...@gentoo.org> wrote: > Matt Turner schrieb: >> On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau <to...@gentoo.org> wrote: >>> >> >> I'm interested in this because I'm regularly annoyed with the emul- >> packages and also because multilib is pretty important for mips. >> >>> If a package has dependencies, then those dependencies are required to have >>> at least the same targets enabled as the package >> >> That seems like the obvious (but perhaps naive) choice. What about >> depending on packages that don't install libraries, like x11-proto/ >> packages or generators like dev-util/indent? >> >> Maybe I just don't understand. Would these packages even have ABI flags? > > All packages do get the ABI flags (with the needed EAPI or via enabled > portage feature, which is currently in the multilib branch). > > If a package does not install anything ABI-specific (no headers, no libs > and no binaries), then there is no overhead, since it will just get > compiled/installed for one ABI, even if multiple ABI flags are enabled.
I suppose that's just for ease of implementation? Not having to special-case packages that don't install binaries. That seem /okay/ to me, but I'm not writing the implementation so I only have so much weight. I would be interested to hear what Ciaran, Brian, and Zac think though. >> It's clear to me that libraries would be installed in different lib* >> directories dependent on their ABI, but how would typical executables >> be handled? > > By default, only the binaries for the first enabled ABI are preserved > (which usually is the default ABI). If you enable the abiwrapper USE > flag, the binaries for all target ABIs are preserved, installed in the > form of $binary-$ABI and $binary will be a symlink to a wrapper, which > calls the right binary for the currently selected ABI. Ahh, I see. That sounds reasonable. >> For mips, we'd like to have gcc built as an n64 binary, which would >> require its run-time dependencies (mpfr, mpc, gmp, etc.) to be >> available as n64 as well, but the rest of the system to be n32 >> binaries. Does this fit with your understanding (and proposed >> solution) of the problem? > > I guess, you require additional n64 libs for gcc dependencies like mpfr, > mpc and others, while your default ABI will be n32. > > This should work fine with my proposal, you just have the (already > default enabled) n32 ABI flag enabled, which results in everything being > built just for n32. For the packages, where you require additional n64 > libs, you just enable the n64 ABI flag in addition. And if you need n64 > binaries too, you enable the abiwrapper USE flag for them. One follow-on question. Consider having a package dev-libs/libpkg already installed for ABI="n32 -n64" and wanting to emerge another package that depends on it with ABI="-n32 n64". Will dev-libs/libpkg have to be rebuilt twice (once for the existing n32 ABI and again for the newly needed n64), or can we optimize this case by recognizing that building for multiple ABIs means entirely separate builds? Thanks, Matt
