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