1 |
Hi James, |
2 |
|
3 |
James Le Cuirot <chewi@g.o> writes: |
4 |
|
5 |
>> > What if we want to bootstrap a brand new prefixed system using the |
6 |
>> > crossdev system as SYSROOT? This is the distinct SYSROOT case. The |
7 |
>> > problem is that there is no distinct variable for SYSROOT's prefix |
8 |
>> > and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We |
9 |
>> > therefore cannot do it! If the crossdev prefix is blank then ROOT's |
10 |
>> > must be blank too. |
11 |
>> |
12 |
>> My question: is there a case when both SYSROOT and ESYSROOT are needed? |
13 |
>> As far as I can see, SYSROOT is strictly build-time. Therefore setting |
14 |
>> SYSROOT=<crossdev toolchain path> would be enough for all. |
15 |
>> |
16 |
>> Why did ESYSROOT exist in the first place? Was it only for the sake of |
17 |
>> symmetry, or did I miss something? |
18 |
> |
19 |
> Remember that we now install packages to SYSROOT too. Portage needs to |
20 |
> know the prefix so that it can set EPREFIX when building these |
21 |
> packages. You'll already know that you can't fake EPREFIX by setting |
22 |
> ROOT. We could potentially work out EPREFIX by comparing SYSROOT with |
23 |
> BROOT and EROOT (instead of / and ROOT) but that's not the whole story. |
24 |
> |
25 |
> When using crossdev, pkg-config files are sourced from SYSROOT. These |
26 |
> may return paths like -L/myprefix/usr/lib. If SYSROOT!=/ then |
27 |
> pkg-config will need to translate this to -L/myroot/myprefix/usr/lib. |
28 |
> However, it's bad to explicitly add lib and include paths that the |
29 |
> toolchain would look at anyway as it can change the search order. Under |
30 |
> a regular setup, pkg-config would omit -L/usr/lib -I/usr/include but for |
31 |
> this to work in the above setup, we need to know that /myprefix is a |
32 |
> prefix. As stated, we don't have an explicit variable for SYSROOT's |
33 |
> prefix but we can work it out using ${ESYSROOT#${SYSROOT}}. This is |
34 |
> what I have done in my pending cross-pkg-config fixes. |
35 |
> |
36 |
> None of that magic happens when not using crossdev. I have debated |
37 |
> whether it should but native builds with SYSROOT!=/ tend to be a |
38 |
> disaster for various other reasons so perhaps it's not worth worrying |
39 |
> about. |
40 |
> |
41 |
> There are probably more reasons when we need to know the prefix but I |
42 |
> can't remember what they are now. :) |
43 |
|
44 |
I could only remotely understand your argument. But I feel you know |
45 |
what you are doing. So go ahead. |
46 |
|
47 |
And please excuse me if I raise this again in the future. |
48 |
|
49 |
>> In conclusion, IMHO, if SYSROOT can be overridden without restriction |
50 |
>> ("distinct" in your email), we could cover all the use cases. |
51 |
> |
52 |
> It's still a little bit restricted but less than it was and the only |
53 |
> cases we don't handle are obscure ones that we wouldn't want to support |
54 |
> anyway. |
55 |
> |
56 |
> When dealing with this stuff, it's worth remembering that practically no |
57 |
> one has used crossdev with prefix until recently. I know this because |
58 |
> I had to fix the glibc ebuild, Portage, and crossdev itself to make it |
59 |
> work following a bug report this month. ;) |
60 |
|
61 |
That is an heroic effort. |
62 |
|
63 |
I have tried to bring together crossdev and Prefix together in the past |
64 |
but found too many obstacles to achieve it. |
65 |
|
66 |
Thank you a million times! |
67 |
|
68 |
Yours, |
69 |
Benda |