1 |
Hello, |
2 |
|
3 |
Following the success of python-r1, the batch of patches I was sending |
4 |
recently and some random testing, I'd like to introduce my ideas |
5 |
and plans on how multilib could be introduced to gx86 in a simple |
6 |
and sane manner. |
7 |
|
8 |
My major goal with this mail is to summarize the ideas, the problems |
9 |
and all the work that has been done already. |
10 |
|
11 |
|
12 |
1. The USE flags and profiles |
13 |
----------------------------- |
14 |
|
15 |
The first step in introducing multilib would be to provide the USE |
16 |
flags necessary to control building for respective ABIs in profiles. |
17 |
The current proposed patches based on simple amd64 multilib are |
18 |
available in [1]. |
19 |
|
20 |
From profiles PoV: |
21 |
|
22 |
1. Each multilib-capable arch set provides USE_EXPAND with relevant |
23 |
multilib profiles. |
24 |
|
25 |
ABI_X86="32 x32 64" |
26 |
ABI_MIPS="o32 n32 n64" |
27 |
|
28 |
2. All the USE_EXPAND variables are hidden in the base profile, and all |
29 |
the flags are masked. |
30 |
|
31 |
3. Every arch relevant to the particular set of multilib flags unmasks |
32 |
and forces the flag for default ABI. |
33 |
|
34 |
x86 -> unmasks & forces abi_x86_32 |
35 |
amd64 -> unmasks & forces abi_x86_64 |
36 |
|
37 |
4. Every multilib profile unmasks the flags for remaining supported |
38 |
ABIs and unhides the variable. |
39 |
|
40 |
amd64 multilib -> unmasks abi_x86_32, unhides ABI_X86 |
41 |
|
42 |
[1]:http://thread.gmane.org/gmane.linux.gentoo.devel/83341 |
43 |
|
44 |
|
45 |
2. The USE flags and packages |
46 |
----------------------------- |
47 |
|
48 |
The packages requesting multilib support either inherit |
49 |
the multilib-build [2] or its derivative (e.g. autotools-multilib), |
50 |
or implement the necessary facilities by hand. |
51 |
|
52 |
The following common rules apply (they are all handled by the eclass): |
53 |
|
54 |
1. Each multilib-capable ebuilds adds multilib flags for all arches |
55 |
to IUSE (IUSE must be constant). |
56 |
|
57 |
2. The relevant set of flags is enforced through profile flag masking, |
58 |
forcing and USE_EXPAND hiding. Therefore, the user only sees |
59 |
the flags which are really relevant. |
60 |
|
61 |
x86, amd64 no-multilib -> no flags (hidden) |
62 |
amd64 multilib -> ABI_X86="32 (64)" (latter forced) |
63 |
|
64 |
3. The enabled set of ABIs is further filtered through MULTILIB_ABIS |
65 |
set by profile. Therefore, even with users mangling the masks they |
66 |
won't be able to build something irrelevant to the profile. |
67 |
|
68 |
4. All the build and libdir details are handled by the multilib.eclass. |
69 |
Therefore, all ebuilds should be ready for it already. |
70 |
|
71 |
5. If no relevant USE flags are selected (bug-case), fallback |
72 |
to default ABI is done. |
73 |
|
74 |
[2]:http://thread.gmane.org/gmane.linux.gentoo.devel/83322 |
75 |
|
76 |
|
77 |
3. Inter-package dependencies |
78 |
----------------------------- |
79 |
|
80 |
The inter-package dependencies are done the best way possible -- |
81 |
explicitly ;). The package developers are supposed to know best which |
82 |
of the dependencies need having same ABIs enabled and which don't. |
83 |
|
84 |
1. The 'regular' multilib packages are supposed to use |
85 |
${MULTILIB_USEDEP} from multilib-build.eclass on all dependencies |
86 |
which need multilib. |
87 |
|
88 |
RDEPEND="dev-libs/libfoo[${MULTILIB_USEDEP}] |
89 |
dev-libs/libbar[ssl,${MULTILIB_USEDEP}]" |
90 |
|
91 |
The dependencies will be required to have the same ABIs enabled |
92 |
as the package in question. |
93 |
|
94 |
2. The specific cases can use the USE flags directly. For example, |
95 |
binary x86 packages can depend on abi_x86_32 unconditionally: |
96 |
|
97 |
RDEPEND="dev-libs/libfoo[abi_x86_32]" |
98 |
|
99 |
Due to proper profile USE flag forcing/masking, that dependency is |
100 |
valid both for amd64 multilib & real x86 system. |
101 |
|
102 |
|
103 |
4. ABI-specific content |
104 |
----------------------- |
105 |
|
106 |
The gx86 multilib assumes that the majority of multilib packages will |
107 |
install only 32-bit libraries and pkg-config files. |
108 |
|
109 |
1. The installation of 32-bit data in libdir is done implicitly through |
110 |
multilib.eclass and econf awareness of ABI variable. |
111 |
|
112 |
2. Any other content which needs to be ABI-aware (includes, *-config |
113 |
programs) need be handled by ebuilds explicitly. |
114 |
|
115 |
3. Additionally, the autotools-multilib.eclass will ensure that headers |
116 |
installed to /usr/include are consistent between ABIs. |
117 |
|
118 |
|
119 |
5. Solutions to specific problems |
120 |
--------------------------------- |
121 |
|
122 |
1. x11-proto packages |
123 |
|
124 |
Those packages install headers to /usr/include and pkg-config files |
125 |
to /usr/lib64. This supposedly means that the headers could be |
126 |
ABI-specific; however, so far I haven't seen a single difference. |
127 |
|
128 |
Possible solutions: |
129 |
|
130 |
a) check the headers by hand, move pkg-config files to /usr/share, |
131 |
|
132 |
b) make the proto packages multilib. This will cause identical .pc |
133 |
files to be installed to lib32 & lib64 but will also enable eclass |
134 |
checks for header consistency. |
135 |
|
136 |
|
137 |
2. packages which install ABI-dependent headers |
138 |
|
139 |
e.g. libogg. The issue needs to be fixed in the specific ebuild. |
140 |
|
141 |
a) fix the headers, e.g.: |
142 |
|
143 |
typedef short ogg_int16_t; |
144 |
typedef unsigned short ogg_uint16_t; |
145 |
typedef int ogg_int32_t; |
146 |
|
147 |
to: |
148 |
|
149 |
#include <stdint.h> |
150 |
|
151 |
typedef int16_t ogg_int16_t; |
152 |
... |
153 |
|
154 |
b) install the header(s) in an alternate location. With packages using |
155 |
pkg-config, that would be easy. |
156 |
|
157 |
|
158 |
3. packages which still reinvent pkg-config with their *-config |
159 |
|
160 |
e.g. llvm. Really painful to solve; probably will require action both |
161 |
on llvm ebuild side and consumer side. |
162 |
|
163 |
a) long-term solution: convince upstream to use pkg-config. |
164 |
|
165 |
b) short-term: rename the llvm-config script and use the renamed |
166 |
version for 32-bit build. |
167 |
|
168 |
|
169 |
What are your thoughts? |
170 |
|
171 |
-- |
172 |
Best regards, |
173 |
Michał Górny |