1 |
Mike Frysinger schrieb: |
2 |
> On Sunday 18 October 2009 14:46:07 Thomas Sachau wrote: |
3 |
>> Mike Frysinger schrieb: |
4 |
>>> another quick look at _setup_abi_env() looks like it needs work: |
5 |
>>> - LD should not default to `ld` |
6 |
>> Whats your suggestion? |
7 |
> |
8 |
> the majority of the time, the compiler driver (i.e. `gcc`) should be used for |
9 |
> linking. very few packages should invoke the linker directly. that is why |
10 |
> currently the toolchain-func.eclass has tc-getLD return `ld` -- a few packages |
11 |
> need it, but not most. if we're going to be forcing the setting of the LD env |
12 |
> var all the time, then it needs to default to ${CC}. packages that need funky |
13 |
> behavior should still work as they will be calling $(tc-getLD) anyways. |
14 |
|
15 |
Dropped $LD for now, seems to work fine for me. |
16 |
|
17 |
> |
18 |
>>> - the -L paths to system dirs in LDFLAGS should not be there -- the |
19 |
>>> toolchain can handle these just fine |
20 |
>> Last time i tried without, some packages failed to compile, will test it |
21 |
>> again to check, if its still needed |
22 |
> |
23 |
> if things are failing, then we should look at gcc/binutils to make sure they |
24 |
> use the right default search paths when given -m32/-m64 |
25 |
|
26 |
I currently dont export any explicit LDFLAGS, but instead only save the value at the end of each |
27 |
phase, seems to work fine for me. |
28 |
|
29 |
> |
30 |
>>> how do you control whether the multilib headers are needed ? it'll |
31 |
>>> probably make sense in general, but there are def some packages where |
32 |
>>> this will only get in the way (the toolchain ones). |
33 |
>> What do you mean here? If the diff between ABIs makes sense to install |
34 |
>> seperate versions? |
35 |
> |
36 |
> some packages (like glibc and linux-headers) already handle the multilib |
37 |
> situation. forcing the unnecessary Gentoo layer into the stack can easily |
38 |
> break things. |
39 |
|
40 |
For glibc, it is avoided since it has the "multilib" useflag. If this is enabled, it indicates for |
41 |
me that the package does handle everything for itself, so multilib-portage does handle it as if it |
42 |
would be a normal package without multi-ABI request. |
43 |
Since linux-headers do also some special multilib handling, could you also add a "multilib" useflag |
44 |
for them? Currently i have an exception for them in my code to prevent problems for other packages. |
45 |
|
46 |
I assume that ever package not having a multilib useflag does not any multilib-specific action. To |
47 |
check, if the header files differ per ABI, i save them for both ABIs, then diff them and create |
48 |
ABI-specific header files with a wrapper for all header files, that differ. The rest is just |
49 |
installed as usual. |
50 |
|
51 |
>>> how do you differentiate between packages where multi ABIs make no sense |
52 |
>>> ? for example, most packages that dont install any libraries but just |
53 |
>>> binaries. let's use the simple package app-text/tree. |
54 |
>> I dont differentiate. Currently i build for every ABI, if lib32 useflag is |
55 |
>> set and multilib useflag is not set. The idea behind it is to allow the |
56 |
>> installation of additional 32bit binaries, if requested. |
57 |
> |
58 |
> that's is an immense waste of time. if we ran all the source phases for a |
59 |
> single ABI in one go, it should be easy to dynamically detect when a multilib |
60 |
> multipass is necessary (by looking at library paths in $D). and for the odd |
61 |
> package out, create a hook of some sort (EMULTIABI=true) to force behavior. |
62 |
> |
63 |
> i dont think there is any inherit reliance on running the multilib pass on |
64 |
> each src step every time (other than that was easiest to implement) ? |
65 |
|
66 |
For packages with header files, i need to run all phases for both ABIs to check, if the header files |
67 |
are ABI specific. |
68 |
So it would require a check for installed libs and installed header files. And its more work since |
69 |
it requires both changes to the ebuild and emerge command. |
70 |
|
71 |
> |
72 |
>>> a lot of this multilib code should probably continue to live in the tree |
73 |
>>> as it's a pretty big base of code to formalize that could do with fixes |
74 |
>>> over time. i.e. we figure out that certain paths / define protections |
75 |
>>> dont work so well, so changing them to something else would require PMS |
76 |
>>> changing !? there has been talk before about pushing a lot of basic |
77 |
>>> stuff to the tree so things dont have to be encoded in the PMS. |
78 |
>> How do you want to do this? Require package managers to inherit some |
79 |
>> file/eclass? |
80 |
> |
81 |
> considering this requires changes to the PM already, i dont see why not. and |
82 |
> it wouldnt really be an inherit in the current sense of the word. more like a |
83 |
> simple source. |
84 |
|
85 |
I am ok with this suggestion. |
86 |
|
87 |
> |
88 |
>>> how are packages handled that can only be used via 1 ABI ? any of the |
89 |
>>> packages listed in the amd64 no-multilib package.mask for example. while |
90 |
>>> these are mostly binary-only, this isnt a binary-specific issue. there |
91 |
>>> are a number of packages which only work on x86/ppc but could easily work |
92 |
>>> in a multilib amd64/ppc64 as a 32bit binary (source code sucks, is |
93 |
>>> heavily asm, something else). |
94 |
>> The binary-only ones are easy. Since they dont interact with the env, they |
95 |
>> can be installed as usual. If they depend on a new enough package manager |
96 |
>> with multilib support, they could also depend on the useflag for the |
97 |
>> additional 32bit libs they need. |
98 |
> |
99 |
> if it's a binary package, we know the ABI of it ahead of time. so if the |
100 |
> package declared the binary ABI that it uses, then portage could handle the |
101 |
> rest (making sure the deps are resolved against the ABI that it requires). we |
102 |
> dont want to rewrite every binary ebuild to include an explicit [foo] ABI flag |
103 |
> on each of its deps. |
104 |
|
105 |
This would require additional vars for multilib handling, which would require inclusion in EAPI-3 or |
106 |
in a future EAPI, if the current process with EAPIs is continued. |
107 |
|
108 |
With the current implementation, i try to stay EAPI-independent, so the changes can be implemented |
109 |
without having to wait for aproval of another EAPI. |
110 |
|
111 |
> |
112 |
>>>> 2. Adding the internal lib32 useflag and usedeps with some workarounds |
113 |
>>> what exactly does this "lib32" do ? naming USE flags according to |
114 |
>>> specific ABI implementations is a bad idea. you have to forget special |
115 |
>>> casing anything to "lib32 vs lib64". amd64, while the most common, is |
116 |
>>> hardly extensible. we must handle multiple ABIs which easily might have |
117 |
>>> the same bitsize. |
118 |
>> "lib32" is added to IUSE, you can enable as as every other useflag. |
119 |
>> Internally, portage does add [lib32?] usedeps to all dependencies. So if |
120 |
>> you enable the lib32 useflag, portage will require this useflag for all |
121 |
>> dependencies too. I dont mind renaming it, if there is some other sane |
122 |
>> naming for it. |
123 |
> |
124 |
> i think every package will need tagging for each ABI, not just relative to the |
125 |
> default one. so the profile on an amd64 multilib would declare that it wants |
126 |
> both x86 and x86_64 binaries by default. in the normal case, the PM can then |
127 |
> automatically resolve all dependencies as requiring all ABIs. if a binary |
128 |
> package is emerged, the ebuild itself declares the ABIs it provides, and then |
129 |
> the PM only resolves the dependencies for the ABIs the package provides. |
130 |
|
131 |
In general, this looks ok. As said above, i just want to prevent the multilib-implementation from |
132 |
being delayed until another EAPI is created, aproved and implemented. |
133 |
|
134 |
-- |
135 |
Thomas Sachau |
136 |
|
137 |
Gentoo Linux Developer |