1 |
It was originally envisaged (but not stated in PMS) that SYSROOT would |
2 |
only ever need to equal / or ROOT as a distinct SYSROOT would have no |
3 |
benefit. A check was added to Portage to ensure this held. Myself, the |
4 |
ChromiumOS team, and others have since been caught out by this check |
5 |
when trying to bootstrap brand new systems from scratch. You cannot |
6 |
bootstrap with no headers at all! The check will therefore be adjusted |
7 |
to merely ensure that SYSROOT is / when ROOT is /. |
8 |
|
9 |
There were differing assumptions about how prefixes applied to the |
10 |
above. EPREFIX is traditionally something the user sets so some |
11 |
thought that it would be applied to SYSROOT, regardless of the |
12 |
latter's value. In order to honor the rule about there being no |
13 |
distinct SYSROOT, this would mean that if SYSROOT is / then EPREFIX |
14 |
would have to match BROOT. Despite that limitation, ESYSROOT was |
15 |
written into PMS with a fixed value of ${SYSROOT}${EPREFIX}. Being |
16 |
somewhat unfamiliar with prefix at the time, I didn't realise that |
17 |
this view didn't align with what I'd had in mind and it was only when |
18 |
I came to need a distinct SYSROOT that I realised there was a problem. |
19 |
|
20 |
crossdev toolchains are installed to ${EPREFIX}/usr/${CHOST} but have |
21 |
no further prefix appended and packages subsequently installed with |
22 |
cross-emerge are placed in this location by setting ROOT. Bug #642604 |
23 |
recently revealed that the build system's prefix was being erroneously |
24 |
duplicated on the end but I have now fixed this. |
25 |
|
26 |
What if we want to bootstrap a brand new prefixed system using the |
27 |
crossdev system as SYSROOT? This is the distinct SYSROOT case. The |
28 |
problem is that there is no distinct variable for SYSROOT's prefix |
29 |
and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We |
30 |
therefore cannot do it! If the crossdev prefix is blank then ROOT's |
31 |
must be blank too. |
32 |
|
33 |
I also never intended to have the aforementioned limitation where |
34 |
EPREFIX must match BROOT when SYSROOT is /. These are both entirely |
35 |
artificial restrictions. |
36 |
|
37 |
So how should it work instead? We originally intended for SYSROOT to |
38 |
equal either / or ROOT so I imagined the prefix would automatically be |
39 |
adjusted to match the prefix applicable at the matching location, |
40 |
namely BROOT or EPREFIX. This is obviously more flexible than forcing |
41 |
it to match EPREFIX. |
42 |
|
43 |
What about the distinct SYSROOT case? With no distinct variable, we |
44 |
have no way to explicitly set a prefix but this is likely only needed |
45 |
when bootstrapping against crossdev systems, which are unprefixed by |
46 |
nature. We therefore simply assume that the prefix is blank in this |
47 |
case. |
48 |
|
49 |
What about the cross-prefix case? Here, SYSROOT matches both / and |
50 |
ROOT so which prefix do we choose? The bootstrap-prefix.sh script sets |
51 |
flags to build against the target prefix so EPREFIX is used in this |
52 |
case. This happens to fit the current definition of ESYSROOT anyway. |
53 |
|
54 |
Legitimate concerns have been raised about building for a system with |
55 |
a different prefix to the one you're building against. The only |
56 |
binaries that leak from SYSROOT to ROOT are static libraries. Headers |
57 |
from SYSROOT will obviously also influence how ROOT's binaries are |
58 |
built. It is entirely possible that SYSROOT's prefix may leak through |
59 |
a header but grepping /usr/include on my own main system reveals only |
60 |
a few paths from a small handful of packages. pkg-config files |
61 |
invariably include paths but these are almost always used at build |
62 |
time, not runtime. A differing prefix would likely only occur in cases |
63 |
involving core packages like the libc and kernel headers anyway. Also |
64 |
consider that we have never prevented this from happening in the |
65 |
past. It has always been possible to do "EPREFIX=/foo emerge bar" from |
66 |
some system with a different prefix or no prefix at all. All we're |
67 |
doing here is including the prefix (if any) in the ESYSROOT variable. |
68 |
|
69 |
Should this warrant a new EAPI? I don't think so. All existing usage |
70 |
of ESYSROOT that I have seen still fits with this new definition and |
71 |
most of that usage has come from me. We're not even changing what the |
72 |
variable is used for, just loosening the constraints around what it |
73 |
can be set to. |
74 |
|
75 |
If you have doubts about whether this makes sense or actually works in |
76 |
practise, I have experimented with a prefixed system using all the |
77 |
different combinations I could think of, including cross-compiling, |
78 |
and it all worked as expected. Keep in mind that ESYSROOT is not magic |
79 |
and currently isn't used very much. As such, neither the toolchain nor |
80 |
pkg-config will use this sysroot if you don't explicitly tell them |
81 |
to. For the former, I find CC="${CHOST}-gcc --sysroot=${ESYSROOT}" |
82 |
works well. For the latter, crossdev installs a cross-pkg-config |
83 |
wrapper but it is completely lacking prefix support at the moment. I |
84 |
have fixes waiting on this change. |
85 |
|
86 |
Signed-off-by: James Le Cuirot <chewi@g.o> |
87 |
--- |
88 |
dependencies.tex | 24 ++++++++++++++++++------ |
89 |
ebuild-env-vars.tex | 7 ++++--- |
90 |
2 files changed, 22 insertions(+), 9 deletions(-) |
91 |
|
92 |
diff --git a/dependencies.tex b/dependencies.tex |
93 |
index 44382d1..fbe99ae 100644 |
94 |
--- a/dependencies.tex |
95 |
+++ b/dependencies.tex |
96 |
@@ -32,13 +32,25 @@ |
97 |
\label{tab:dep-class-api} |
98 |
\begin{tabular}{llll} |
99 |
\toprule |
100 |
- & \t{BDEPEND} & \t{DEPEND} & \t{RDEPEND}, \t{PDEPEND} \\ |
101 |
+ & \t{BDEPEND} & \t{DEPEND} & \t{RDEPEND}, \t{PDEPEND} \\ |
102 |
\midrule |
103 |
- Binary compatible with & \t{CBUILD} & \t{CHOST} & \t{CHOST} \\ |
104 |
- Base unprefixed path & \t{/} & \t{\$\{SYSROOT\}} & \t{\$\{ROOT\}} \\ |
105 |
- Relevant offset-prefix & \t{\$\{BROOT\}} & \t{\$\{EPREFIX\}} & \t{\$\{EPREFIX\}} \\ |
106 |
- Path combined with prefix & \t{\$\{BROOT\}} & \t{\$\{ESYSROOT\}} & \t{\$\{EROOT\}} \\ |
107 |
- PM query command option & \t{-b} & \t{-d} & \t{-r} \\ |
108 |
+ Binary compatible with & \t{CBUILD} & \t{CHOST} & \t{CHOST} \\ |
109 |
+ Base unprefixed path & \t{/} & \t{\$\{SYSROOT\}} & \t{\$\{ROOT\}} \\ |
110 |
+ Relevant offset-prefix & \t{\$\{BROOT\}} & See table~\ref{tab:depend-prefix} & \t{\$\{EPREFIX\}} \\ |
111 |
+ Path combined with prefix & \t{\$\{BROOT\}} & \t{\$\{ESYSROOT\}} & \t{\$\{EROOT\}} \\ |
112 |
+ PM query command option & \t{-b} & \t{-d} & \t{-r} \\ |
113 |
+ \bottomrule |
114 |
+ \end{tabular} |
115 |
+\end{centertable} |
116 |
+ |
117 |
+\begin{centertable}{Prefix values for \t{DEPEND} when matching \t{SYSROOT} values from left to right} |
118 |
+ \label{tab:depend-prefix} |
119 |
+ \begin{tabular}{llll} |
120 |
+ \toprule |
121 |
+ If \t{SYSROOT} is: & \t{\$\{ROOT\}} & \t{/} & Other \\ |
122 |
+ \midrule |
123 |
+ Then offset-prefix is: & \t{\$\{EPREFIX\}} & \t{\$\{BROOT\}} & Blank \\ |
124 |
+ And \t{ESYSROOT} is: & \t{\$\{EROOT\}} & \t{\$\{BROOT\}} & \t{\$\{SYSROOT\}} \\ |
125 |
\bottomrule |
126 |
\end{tabular} |
127 |
\end{centertable} |
128 |
diff --git a/ebuild-env-vars.tex b/ebuild-env-vars.tex |
129 |
index 660d17b..8c4d044 100644 |
130 |
--- a/ebuild-env-vars.tex |
131 |
+++ b/ebuild-env-vars.tex |
132 |
@@ -141,9 +141,10 @@ variable. |
133 |
\t{ESYSROOT} & |
134 |
Ditto & |
135 |
No & |
136 |
- Contains the concatenation of the paths in the \t{SYSROOT} and \t{EPREFIX} variables, |
137 |
- for convenience. See also the \t{EPREFIX} variable. Only for EAPIs listed |
138 |
- in table~\ref{tab:offset-env-vars-table} as supporting \t{ESYSROOT}. \\ |
139 |
+ Contains the concatenation of the \t{SYSROOT} path and applicable prefix value. The prefix value |
140 |
+ is \t{EPREFIX}, \t{BROOT}, or blank if \t{SYSROOT} is equal to \t{ROOT}, \t{/}, or something |
141 |
+ else respectively. Only for EAPIs listed in table~\ref{tab:offset-env-vars-table} as supporting |
142 |
+ \t{ESYSROOT}. \\ |
143 |
\t{BROOT} & |
144 |
Ditto & |
145 |
No & |
146 |
-- |
147 |
2.21.0 |