Re: [gentoo-dev] [EAPI 7] Cross-compile improvements (BDEPEND, BROOT, sysroot)

[Mike Frysinger]

On 02 Dec 2015 23:20, James Le Cuirot wrote:
> On reflection, I'm now thinking that we should call it something less
> generic. I also found that the Qt build uses SYSROOT for its own
> purposes so you cannot rely on it in toolchain wrappers. ROOT is
> probably just as unreliable. For that reason, I ended up using
> CB_SYSROOT in cross-boss.

it should be SYSROOT.  we've been using it for years in Chromium OS w/out
problems, it's in the base cross-compiling logic already, it's the obvious
logical name, and it's used by a few ebuilds and upstream packages.

no matter what name you pick you run the risk of colloding with upstream
packages using it for something else.  we've already seen that with the
vars in the spec like ABI, ROOT, and D.

> I forgot to mention earlier that if ROOT were used, PMS actually
> forbids it from being referenced in the src_* phases so this
> restriction would need to be lifted. Relying on the toolchain's
> internal sysroot is not sufficient.

sounds fine to forbid it

> > > gcc and friends support a --sysroot argument. It used to be the case
> > > that this didn't work on a toolchain configured without a sysroot,
> > > possibly creating issues for #4, but I've tested and it now works
> > > regardless.
> >
> > $ gcc --sysroot=/tmp/foo -I/usr/include foo.c
> > /usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> > this linker was not configured to use sysroots
> > collect2: error: ld returned 1 exit status
> >
> > Two problems here:
> > 1. link fails
> > 2. gcc doesn't warn for -I/usr/include with sysroot (iirc crossdev's
> > gcc do)
>
> Yeah, turns out my hello.c test was not sufficient. It seems gcc is
> fine with it but binutils isn't. This seems silly to me so maybe this
> could be patched out or perhaps building the native binutils with
> --with-sysroot=/ would work?

i vaguely recall older versions misbehaving, but should be fixed in the
latest ones.  which is why i haven't enabled it for all builds -- wanted
to make sure things didn't break first w/native.

> I know about -Wpoison-system-directories. We only enable it for
> cross-compilers but I think it only triggers when cross-compiling
> anyway. It's a shame they didn't make it dependent on --sysroot
> instead.

the eclass enables it only when creating cross-compilers.  i could rework
the code to be available all the time and work off of sysroot.  i was going
for conservative on the first pass.
-mike