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