[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: [PMS] [PATCH] Correct the definition of ESYSROOT as EPREFIX isn't always applic
From:       James Le Cuirot <chewi () gentoo ! org>
Date:       2019-07-31 21:40:51
Message-ID: 20190731224051.3a5f65d0 () symphony ! aura-online ! co ! uk
[Download RAW message or body]


On Tue, 30 Jul 2019 23:50:21 +0800
Benda Xu <heroxbd@gentoo.org> wrote:

> > A check was added to Portage to ensure this held. Myself, the
> > ChromiumOS team, and others have since been caught out by this check
> > when trying to bootstrap brand new systems from scratch. You cannot
> > bootstrap with no headers at all! The check will therefore be adjusted
> > to merely ensure that SYSROOT is / when ROOT is /.  
> 
> It is very encouraging to see contributions from the ChromiumOS team to
> Gentoo!

Don't read too much into that. ;) I can't recall how I became aware of
it but I saw a patch that ChromiumOS had made against Portage to remove
the check I had added. No doubt it had caught them out in the same way.

> > What if we want to bootstrap a brand new prefixed system using the
> > crossdev system as SYSROOT? This is the distinct SYSROOT case. The
> > problem is that there is no distinct variable for SYSROOT's prefix
> > and, as already stated, ESYSROOT is always ${SYSROOT}${EPREFIX}. We
> > therefore cannot do it! If the crossdev prefix is blank then ROOT's
> > must be blank too.  
> 
> My question: is there a case when both SYSROOT and ESYSROOT are needed?
> As far as I can see, SYSROOT is strictly build-time. Therefore setting
> SYSROOT=<crossdev toolchain path> would be enough for all.
> 
> Why did ESYSROOT exist in the first place?  Was it only for the sake of
> symmetry, or did I miss something?

Remember that we now install packages to SYSROOT too. Portage needs to
know the prefix so that it can set EPREFIX when building these
packages. You'll already know that you can't fake EPREFIX by setting
ROOT. We could potentially work out EPREFIX by comparing SYSROOT with
BROOT and EROOT (instead of / and ROOT) but that's not the whole story.

When using crossdev, pkg-config files are sourced from SYSROOT. These
may return paths like -L/myprefix/usr/lib. If SYSROOT!=/ then
pkg-config will need to translate this to -L/myroot/myprefix/usr/lib.
However, it's bad to explicitly add lib and include paths that the
toolchain would look at anyway as it can change the search order. Under
a regular setup, pkg-config would omit -L/usr/lib -I/usr/include but for
this to work in the above setup, we need to know that /myprefix is a
prefix. As stated, we don't have an explicit variable for SYSROOT's
prefix but we can work it out using ${ESYSROOT#${SYSROOT}}. This is
what I have done in my pending cross-pkg-config fixes.

None of that magic happens when not using crossdev. I have debated
whether it should but native builds with SYSROOT!=/ tend to be a
disaster for various other reasons so perhaps it's not worth worrying
about.

There are probably more reasons when we need to know the prefix but I
can't remember what they are now. :)

> In conclusion, IMHO, if SYSROOT can be overridden without restriction
> ("distinct" in your email), we could cover all the use cases.

It's still a little bit restricted but less than it was and the only
cases we don't handle are obscure ones that we wouldn't want to support
anyway.

When dealing with this stuff, it's worth remembering that practically no
one has used crossdev with prefix until recently. I know this because
I had to fix the glibc ebuild, Portage, and crossdev itself to make it
work following a bug report this month. ;)

Regards,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[Attachment #3 (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]