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