1 |
Sergei Trofimovich schrieb: |
2 |
> On Sun, 20 Jan 2013 20:11:31 +0100 |
3 |
> Michał Górny <mgorny@g.o> wrote: |
4 |
> |
5 |
>> Hello, |
6 |
>> |
7 |
>> There is a fair interest in multilib and while still early, it would be |
8 |
>> a good moment to decide on how USE flags to use for it. |
9 |
>> |
10 |
>> The current attempts are mostly using USE=multilib which is not really |
11 |
>> expressive and poor. What I would go for is a clear variable specifying |
12 |
>> which targets package is built for. |
13 |
> |
14 |
> You just need to add 'ABI' and 'MULTILIB_ABIS' to |
15 |
> "emerge --info ${pkg}" output. |
16 |
> |
17 |
> Do you plan to keep precise depends for packages? |
18 |
> like glibc[abi_x32]/gcc[abi_x32] for all libraries requesting x32. |
19 |
> |
20 |
> What to do if someone builds a package only with non-default ABI? |
21 |
> (it means installed package does not quite work for default ABI) |
22 |
> |
23 |
> like on ABI=amd64 media-libs/glu[ABI=x32] could not be used by |
24 |
> any of ABI=amd64 users. |
25 |
> |
26 |
> In order to track such depends precisely you would need to add |
27 |
> ABI flags to each revdep recursively. It's quite invasive. Is it worth |
28 |
> the effort? |
29 |
> |
30 |
> Currently USE=multilib means 'build for all toolchain-supported' ABIs. |
31 |
> It looks clean and short. |
32 |
> |
33 |
>> This raises the following questions: |
34 |
>> |
35 |
>> 1) do we want the default ABI to be switchable? |
36 |
> It already is via /etc/portage/env per-package. |
37 |
> Or via profile globally. arch/amd64/make.defaults: |
38 |
> MULTILIB_ABIS="amd64 x86" |
39 |
> DEFAULT_ABI="amd64" |
40 |
> |
41 |
> crossdev allows bootstrapping with any random default |
42 |
> ABI out there as one-liner: |
43 |
> crossdev -A 'x32 amd64' x86_64-unknown-linux-gnu. |
44 |
> |
45 |
>> 2) do we want irrelevant ABIs to be visible to emerge users? |
46 |
>> |
47 |
>> By 2) I mean: do we want the users to see stuff like: |
48 |
>> |
49 |
>> MULTILIB_ABIS="amd64_abi1 amd64_abi2 -amd64_abi3 (-ppc64_abi1) |
50 |
>> (-ppc64_abi2) (-ppc64_abi3) ..." |
51 |
> |
52 |
> Would adding irrelevant ABIs trigger rebuilds on world update? |
53 |
> |
54 |
> Do you intermingle gentoo's $ARCH and ABI? |
55 |
> How many ABI vars do you expect to see for simple "common" cases? |
56 |
> |
57 |
> x86_64-pc-linux-gnu-gcc -m32 (host ARCH=amd64) |
58 |
> x86_64-pc-linux-gnu-gcc -m64 (host ARCH=amd64) |
59 |
> x86_64-pc-linux-gnu-gcc -mx32 (host ARCH=amd64) |
60 |
> i686-pc-linux-gnu-gcc -m32 (host ARCH=x86) |
61 |
> i686-pc-linux-gnu-gcc -m64 (host ARCH=x86) |
62 |
> i686-pc-linux-gnu-gcc -mx32 (host ARCH=x86) |
63 |
> |
64 |
> 3 or 6? |
65 |
> |
66 |
> Looks like insane amount of metadata growth for each |
67 |
> plagued package. |
68 |
> |
69 |
>> or just the relevant part. |
70 |
>> |
71 |
>> To be honest, I don't know if there's other way to hide USE flags than |
72 |
>> using USE_EXPAND_HIDDEN. If we want to use that, we'd have to split |
73 |
>> the flags per-arch, i.e. have: |
74 |
>> |
75 |
>> MULTILIB_AMD64="abi1 abi2 abi3" |
76 |
>> MULTILIB_PPC64="abi1 abi2 abi3" |
77 |
>> |
78 |
>> with appropriate USE_EXPAND_HIDDEN set by profiles. |
79 |
> |
80 |
> Having direct support in portage's core might reduce amount of |
81 |
> user-visible/storable metadata in main tree. No slightest idea |
82 |
> how it would look like though. |
83 |
> |
84 |
|
85 |
Support for cross-compiling packages for toolchain-supported ABIs |
86 |
already exists and works for some years in multilib-portage (code in the |
87 |
multilib branch of portage git repo, ebuild in the multilib-portage |
88 |
overlay with very basic setup instructions in the doc dir of the overlay |
89 |
and the #gentoo-multilib-overlay channel in freenode for questions). |
90 |
|
91 |
-- |
92 |
|
93 |
Thomas Sachau |
94 |
Gentoo Linux Developer |