| 1 |
On Tue, 30 Jul 2019 23:50:21 +0800 |
| 2 |
Benda Xu <heroxbd@g.o> wrote: |
| 3 |
|
| 4 |
> > A check was added to Portage to ensure this held. Myself, the |
| 5 |
> > ChromiumOS team, and others have since been caught out by this check |
| 6 |
> > when trying to bootstrap brand new systems from scratch. You cannot |
| 7 |
> > bootstrap with no headers at all! The check will therefore be adjusted |
| 8 |
> > to merely ensure that SYSROOT is / when ROOT is /. |
| 9 |
> |
| 10 |
> It is very encouraging to see contributions from the ChromiumOS team to |
| 11 |
> Gentoo! |
| 12 |
|
| 13 |
Don't read too much into that. ;) I can't recall how I became aware of |
| 14 |
it but I saw a patch that ChromiumOS had made against Portage to remove |
| 15 |
the check I had added. No doubt it had caught them out in the same way. |
| 16 |
|
| 17 |
> > What if we want to bootstrap a brand new prefixed system using the |
| 18 |
> > crossdev system as SYSROOT? This is the distinct SYSROOT case. The |
| 19 |
> > problem is that there is no distinct variable for SYSROOT's prefix |
| 20 |
> > and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We |
| 21 |
> > therefore cannot do it! If the crossdev prefix is blank then ROOT's |
| 22 |
> > must be blank too. |
| 23 |
> |
| 24 |
> My question: is there a case when both SYSROOT and ESYSROOT are needed? |
| 25 |
> As far as I can see, SYSROOT is strictly build-time. Therefore setting |
| 26 |
> SYSROOT=<crossdev toolchain path> would be enough for all. |
| 27 |
> |
| 28 |
> Why did ESYSROOT exist in the first place? Was it only for the sake of |
| 29 |
> symmetry, or did I miss something? |
| 30 |
|
| 31 |
Remember that we now install packages to SYSROOT too. Portage needs to |
| 32 |
know the prefix so that it can set EPREFIX when building these |
| 33 |
packages. You'll already know that you can't fake EPREFIX by setting |
| 34 |
ROOT. We could potentially work out EPREFIX by comparing SYSROOT with |
| 35 |
BROOT and EROOT (instead of / and ROOT) but that's not the whole story. |
| 36 |
|
| 37 |
When using crossdev, pkg-config files are sourced from SYSROOT. These |
| 38 |
may return paths like -L/myprefix/usr/lib. If SYSROOT!=/ then |
| 39 |
pkg-config will need to translate this to -L/myroot/myprefix/usr/lib. |
| 40 |
However, it's bad to explicitly add lib and include paths that the |
| 41 |
toolchain would look at anyway as it can change the search order. Under |
| 42 |
a regular setup, pkg-config would omit -L/usr/lib -I/usr/include but for |
| 43 |
this to work in the above setup, we need to know that /myprefix is a |
| 44 |
prefix. As stated, we don't have an explicit variable for SYSROOT's |
| 45 |
prefix but we can work it out using ${ESYSROOT#${SYSROOT}}. This is |
| 46 |
what I have done in my pending cross-pkg-config fixes. |
| 47 |
|
| 48 |
None of that magic happens when not using crossdev. I have debated |
| 49 |
whether it should but native builds with SYSROOT!=/ tend to be a |
| 50 |
disaster for various other reasons so perhaps it's not worth worrying |
| 51 |
about. |
| 52 |
|
| 53 |
There are probably more reasons when we need to know the prefix but I |
| 54 |
can't remember what they are now. :) |
| 55 |
|
| 56 |
> In conclusion, IMHO, if SYSROOT can be overridden without restriction |
| 57 |
> ("distinct" in your email), we could cover all the use cases. |
| 58 |
|
| 59 |
It's still a little bit restricted but less than it was and the only |
| 60 |
cases we don't handle are obscure ones that we wouldn't want to support |
| 61 |
anyway. |
| 62 |
|
| 63 |
When dealing with this stuff, it's worth remembering that practically no |
| 64 |
one has used crossdev with prefix until recently. I know this because |
| 65 |
I had to fix the glibc ebuild, Portage, and crossdev itself to make it |
| 66 |
work following a bug report this month. ;) |
| 67 |
|
| 68 |
Regards, |
| 69 |
-- |
| 70 |
James Le Cuirot (chewi) |
| 71 |
Gentoo Linux Developer |
Archives