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