1 |
On Thu, 1 Aug 2019 16:27:22 +0200 |
2 |
Alexis Ballier <aballier@g.o> wrote: |
3 |
> |
4 |
> > What I am trying to say (somewhat unsuccessfully!) is that the value |
5 |
> > of (E)SYSROOT only changes how the package is built, not what the |
6 |
> > resulting package looks like. It's where all the headers and libraries |
7 |
> > are sourced from at build time, which is irrelevant at runtime. |
8 |
> |
9 |
> err, SYSROOT does change what the resulting package looks like: it |
10 |
> defines ABI (headers and needed entries for example). |
11 |
|
12 |
Well yes, in that sense it changes the resulting package but not in a |
13 |
way that is significant here. Say you build a binpkg against SYSROOT A |
14 |
that has libfoo-X and the same package against SYSROOT B that has |
15 |
libfoo-Y. The resulting binpkgs may differ but it would be just the |
16 |
same if you upgraded libfoo-X to libfoo-Y in SYSROOT A and built the |
17 |
binpkg again. Your build system package versions aren't frozen in time |
18 |
forever, right? |
19 |
|
20 |
This doesn't mean that building your binpkgs against different SYSROOTs |
21 |
is a great idea but it's not like this is going to happen by itself. |
22 |
Despite ESYSROOT being influenced by ROOT, changing ROOT at install |
23 |
time obviously isn't going to send your binpkgs into a time machine to |
24 |
be rebuilt with a different ESYSROOT value. |
25 |
|
26 |
Even at build time, I don't expect ESYSROOT to change under your feet. |
27 |
This is simply about automatically giving it a meaningful value based |
28 |
on other variables that are also not going to change at build time. |
29 |
|
30 |
> > So why does ROOT affect it? Normally you install the packages for |
31 |
> > BDEPEND, DEPEND, and RDEPEND to the same location. If BDEPEND and |
32 |
> > RDEPEND are installed to different locations (ROOT!=/) then DEPEND |
33 |
> > will almost always be installed to one of the other two. If either of |
34 |
> > those two locations is prefixed then we need the prefix for DEPEND's |
35 |
> > location to match, otherwise it wouldn't actually be the same |
36 |
> > location. Using ROOT allows us to figure this out automatically in a |
37 |
> > way that covers all sensible use cases and avoids accidentally |
38 |
> > falling into an unsupported case. |
39 |
> |
40 |
> |
41 |
> So, now let's simplify this a bit and forget about prefix and crossdev |
42 |
> for a moment. Say I am building an atom chroot (for nfs root) on an |
43 |
> haswell desktop. I set ROOT=SYSROOT=/atomchroot. My desktop has CFLAGS |
44 |
> for haswell, and I have atom CFLAGS in |
45 |
> /atomchroot/etc/portage/make.conf. When I build something and portage |
46 |
> installs a BDEPEND to /, I want it to use my / configuration, and when |
47 |
> it is in /atomchroot I want it to use the configuration from there. |
48 |
> emerge has command line options to do that but I am not sure if this is |
49 |
> properly specified in PMS. |
50 |
> |
51 |
> |
52 |
> Now, say I am doing the same on a prefix haswell desktop. With your |
53 |
> algorithm, we have SYSROOT==ROOT so ESYSROOT is EPREFIX/SYSROOT. |
54 |
> However, what I want is a normal chroot with EPREFIX=/ here, so when |
55 |
> should one use ESYSROOT in an ebuild in that case ? where does this |
56 |
> EPREFIX comes from by the way ? |
57 |
> |
58 |
> |
59 |
> To me, this looks more of a general problem of defining where the |
60 |
> configuration is taken from, so that we can set EPREFIX independently |
61 |
> if it is SYSROOT or BROOT. |
62 |
|
63 |
First off, you said that ESYSROOT would be EPREFIX/SYSROOT when it |
64 |
would actually be SYSROOT/EPREFIX. I don't know whether that was a typo |
65 |
or genuine confusion. I'll assume the former. |
66 |
|
67 |
I think I see why you're having trouble following this though. EPREFIX |
68 |
is the prefix of the system you're building for and eventually |
69 |
installing to. It has nothing to do with the system you're building on |
70 |
or even the system you're building against. |
71 |
|
72 |
The prefix for the system you're building on is BROOT. I initially |
73 |
suggested the name BPREFIX but it was argued that it should be a *ROOT |
74 |
variable because being rooted at / makes it an absolute path. Before |
75 |
EAPI 7, we didn't have a proper variable for this so, for lack of |
76 |
anything better, some people used EPREFIX. This was fine until you hit |
77 |
the cross-prefix case, which is what you have described above. The true |
78 |
value has also been available as PORTAGE_OVERRIDE_EPREFIX but, as the |
79 |
name suggests, this is an internal Portage variable. |
80 |
|
81 |
So in your example, you want EPREFIX=/ (or more accurately, blank) and |
82 |
that's fine so you would define it as such. You would also define |
83 |
SYSROOT=/atomchroot. As per PMS, ESYSROOT=${SYSROOT}/${EPREFIX} so the |
84 |
actual calculated value of ESYSROOT would also be /atomchroot. |
85 |
|
86 |
You're building on your prefixed Haswell system so BROOT would |
87 |
automatically be set to /haswellprefix or something. You've already |
88 |
defined EPREFIX=/ so where does the BROOT value actually come from? |
89 |
It's hard coded into your prefixed Portage installation, in const.py |
90 |
to be precise. The variable in that file is confusingly named EPREFIX |
91 |
but that's simply because it predates BROOT. You can override this |
92 |
value by defining the environment variable PORTAGE_OVERRIDE_EPREFIX but |
93 |
I can't think of any legitimate reason to do that. |
94 |
|
95 |
I should add that your example is not a case we readily support. |
96 |
Although we've broken down many of the barriers, native builds where |
97 |
SYSROOT!=/ tend to blow up. If / is up to date and configured |
98 |
similarly, you might get away with it. If glibc is older then binaries |
99 |
that have just been built will fail to run at build time. If other |
100 |
libraries have different sonames then binaries needing them will also |
101 |
fail to run at build time. This isn't a problem when cross-compiling |
102 |
because you can never run those binaries anyway! For native builds, it |
103 |
is far simpler to just build in a chroot instead. |
104 |
|
105 |
Any better? |
106 |
|
107 |
-- |
108 |
James Le Cuirot (chewi) |
109 |
Gentoo Linux Developer |