On Saturday 26 December 2009 08:15:22 Thomas Sachau wrote: > On 12/26/2009 11:25 AM, Fabian Groffen wrote: > > This is about what I understood. Now here I have some questions that > > may or may not be relevant. > > > > What triggers a multilib build? Is it unconditional, or can it be > > turned on/off per package? How does Portage resolve/verify that a > > library is built for the right ABI in that case? > > Currently multilib-portage does add a USE flag called "lib32". If you > enable it, you will get the cross-compile, else just the normal install. > In addition this flag is internally used like an EAPI-2 usedep, so it will > require the dependencies to be built for all ABIs too.
this is something that needs to be fixed per the earlier discussion
> > Unpacking sources many times feels like a terrible waste to me,
> > especially for things like GCC. If we would just start building outside
> > of the workdir (sources) into a separate builddir, wouldn't that just
> > be much cleaner and a nice EAPI feature?
>
> That might be an extra step, once the basic implementation works, but you
> will have to adjust some things, since e.g. cmake-utils eclass does
> already something like that, maybe others do it too, so you would have to
> change those ebuilds/eclasses or add exceptions or extra rules to portage
> for those. Some packages like gcc or glibc already do this multilib-stuff
> internally with the multilib USE flag, so you currently wont get any
> better experience for them.
indeed ... it'd be nice if we only ran src_unpack() once, but there are
packages in EAPI0 that modify the source based on ABI/build flags. the only
safe way is to always run the src_unpack() multiple times.
once this implementation settles on top of EAPI{0..3}, we can look at EAPI4+
to optimize the flow.
> > Since you make each compilation multiple times, you also obtain a fully
> > identical installation of the same package. How do you deal with that?
> > Do you have /usr/bin{64,32} directories for example too? If you only
> > keep libs (found by a scanelf scan or something), how do you know what's
> > relevant. Alternatively, if you build the full application anyway,
> > isn't it a waste to throw away the result? You could see multilib also
> > as two (unrelated) trees, such as e.g. a Gentoo Prefix installation.
> > A nasty one: how to deal with libs that actually contain hardcoded paths
> > to configuration from e.g. /etc or /var in your implementation?
>
> Currently i only work and test with amd64-ARCH, so with x86 and amd86 ABI.
> For those, the lib-part is easy since the crosscompile does install the
> libs into /usr/lib32 while the 64bit ones go into /usr/lib64. The headers
> for both ABIs are diffed and different ones are preserved, the rest is
> isntalled as usual. For binaries, normally only the one for the
> DEFAULT_ABI, so in this case the 64bit one, will be preserved. But you can
> tell multilib-portage to preserve the 32bit binaries. In that case, the
> binaries will be called $binary-$ABI and a symlink $binary to a wrapper
> created, which calls the real binary depending on the current ABI.
can you guys think of a package where the bindirs differ and/or we care ?
-mike
signature.asc
Description: This is a digitally signed message part.
