On Thu, 1 Aug 2019 16:27:22 +0200 Alexis Ballier <[email protected]> wrote: > > > What I am trying to say (somewhat unsuccessfully!) is that the value > > of (E)SYSROOT only changes how the package is built, not what the > > resulting package looks like. It's where all the headers and libraries > > are sourced from at build time, which is irrelevant at runtime. > > err, SYSROOT does change what the resulting package looks like: it > defines ABI (headers and needed entries for example).
Well yes, in that sense it changes the resulting package but not in a
way that is significant here. Say you build a binpkg against SYSROOT A
that has libfoo-X and the same package against SYSROOT B that has
libfoo-Y. The resulting binpkgs may differ but it would be just the
same if you upgraded libfoo-X to libfoo-Y in SYSROOT A and built the
binpkg again. Your build system package versions aren't frozen in time
forever, right?
This doesn't mean that building your binpkgs against different SYSROOTs
is a great idea but it's not like this is going to happen by itself.
Despite ESYSROOT being influenced by ROOT, changing ROOT at install
time obviously isn't going to send your binpkgs into a time machine to
be rebuilt with a different ESYSROOT value.
Even at build time, I don't expect ESYSROOT to change under your feet.
This is simply about automatically giving it a meaningful value based
on other variables that are also not going to change at build time.
> > So why does ROOT affect it? Normally you install the packages for
> > BDEPEND, DEPEND, and RDEPEND to the same location. If BDEPEND and
> > RDEPEND are installed to different locations (ROOT!=/) then DEPEND
> > will almost always be installed to one of the other two. If either of
> > those two locations is prefixed then we need the prefix for DEPEND's
> > location to match, otherwise it wouldn't actually be the same
> > location. Using ROOT allows us to figure this out automatically in a
> > way that covers all sensible use cases and avoids accidentally
> > falling into an unsupported case.
>
>
> So, now let's simplify this a bit and forget about prefix and crossdev
> for a moment. Say I am building an atom chroot (for nfs root) on an
> haswell desktop. I set ROOT=SYSROOT=/atomchroot. My desktop has CFLAGS
> for haswell, and I have atom CFLAGS in
> /atomchroot/etc/portage/make.conf. When I build something and portage
> installs a BDEPEND to /, I want it to use my / configuration, and when
> it is in /atomchroot I want it to use the configuration from there.
> emerge has command line options to do that but I am not sure if this is
> properly specified in PMS.
>
>
> Now, say I am doing the same on a prefix haswell desktop. With your
> algorithm, we have SYSROOT==ROOT so ESYSROOT is EPREFIX/SYSROOT.
> However, what I want is a normal chroot with EPREFIX=/ here, so when
> should one use ESYSROOT in an ebuild in that case ? where does this
> EPREFIX comes from by the way ?
>
>
> To me, this looks more of a general problem of defining where the
> configuration is taken from, so that we can set EPREFIX independently
> if it is SYSROOT or BROOT.
First off, you said that ESYSROOT would be EPREFIX/SYSROOT when it
would actually be SYSROOT/EPREFIX. I don't know whether that was a typo
or genuine confusion. I'll assume the former.
I think I see why you're having trouble following this though. EPREFIX
is the prefix of the system you're building for and eventually
installing to. It has nothing to do with the system you're building on
or even the system you're building against.
The prefix for the system you're building on is BROOT. I initially
suggested the name BPREFIX but it was argued that it should be a *ROOT
variable because being rooted at / makes it an absolute path. Before
EAPI 7, we didn't have a proper variable for this so, for lack of
anything better, some people used EPREFIX. This was fine until you hit
the cross-prefix case, which is what you have described above. The true
value has also been available as PORTAGE_OVERRIDE_EPREFIX but, as the
name suggests, this is an internal Portage variable.
So in your example, you want EPREFIX=/ (or more accurately, blank) and
that's fine so you would define it as such. You would also define
SYSROOT=/atomchroot. As per PMS, ESYSROOT=${SYSROOT}/${EPREFIX} so the
actual calculated value of ESYSROOT would also be /atomchroot.
You're building on your prefixed Haswell system so BROOT would
automatically be set to /haswellprefix or something. You've already
defined EPREFIX=/ so where does the BROOT value actually come from?
It's hard coded into your prefixed Portage installation, in const.py
to be precise. The variable in that file is confusingly named EPREFIX
but that's simply because it predates BROOT. You can override this
value by defining the environment variable PORTAGE_OVERRIDE_EPREFIX but
I can't think of any legitimate reason to do that.
I should add that your example is not a case we readily support.
Although we've broken down many of the barriers, native builds where
SYSROOT!=/ tend to blow up. If / is up to date and configured
similarly, you might get away with it. If glibc is older then binaries
that have just been built will fail to run at build time. If other
libraries have different sonames then binaries needing them will also
fail to run at build time. This isn't a problem when cross-compiling
because you can never run those binaries anyway! For native builds, it
is far simpler to just build in a chroot instead.
Any better?
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpKOGM4rJ5x1.pgp
Description: OpenPGP digital signature
