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

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 10649 bytes --]

Sorry for the length of this but you really need to consider the bigger
picture with this stuff and not all devs are familiar with it.

For EAPI 7, mgorny and I are seeking to address some cross-compiling
issues. This is a subject I've long had an interest in and before I
became a developer, I created a project called cross-boss that, to be
blunt, hacks its way through the shortcomings in Portage and the tree.
It does (or at least did when I last worked on it) achieve a higher
success rate than you would get from crossdev alone and allows you to
install a brand new standalone system from scratch as opposed to one
under /usr/${CHOST}.

I have heard some developers say that cross-compiling is simply not
worth the effort but I have succeeded in building some big ticket items
including MariaDB, GTK+, Qt4, and LibreOffice. This is one area where
Gentoo can really shine so I would like to exploit that potential.

It is unlikely that I'll be able to negate the need for cross-boss
entirely as some packages can be really stubborn but these changes
should at least allow some of the hacks to be removed.

The first change is a long-standing one and adds BDEPEND to the list of
dependency types. For those familiar with the experimental HDEPEND
implementation, this is the same thing under a different name that many
developers have said they prefer. It means "build depend" for packages
to be installed on / aka the CBUILD system.

You may be thinking that is what DEPEND is for but sometimes you need
to differentiate between build-time dependencies that are needed in /
for execution and those that are needed in ROOT for headers, static
libraries, and other things.

This is best illustrated with an example. pam currently DEPENDs on
flex as it links against libfl.a. By default, Portage will not install
DEPEND packages to ROOT so this fails when cross-compiling. flex could
be added to RDEPEND but that is suboptimal and may not be feasible in
other cases. We could run emerge with --root-deps but this tends to
pull in many more packages that play havoc when cross-compiling.

This feature can also be particularly useful for packages like autogen
and dbus-glib that execute themselves during the build. This doesn't
always work when cross-compiling but you can use BDEPEND in conjunction
with the targetroot USE flag (see man 5 ebuild) to install that package
to / first and then use that version to complete the cross build.

So when cross-compiling under EAPI 7, the traditional defaults change.
BDEPEND is installed to / as already stated and DEPEND is now installed
to ROOT. The --root-deps options have no effect. Won't this break
cross-compiling for future EAPI 7 ebuilds and eclasses that haven't
been given the BDEPEND treatment? Yes and no. crossdev's cross-emerge
wrapper has long included the --root-deps=rdeps option by default,
which simply throws DEPEND away and this is equally broken already.

So why did crossdev include --root-deps=rdeps in the first place if it
breaks things? The commit message doesn't really say and solar doesn't
seem to be around to answer that question. I'm guessing it was a
trade-off to save time. Portage currently installs all of DEPEND to /
by default even though most of those dependencies are solely needed
for headers and libraries. This means that when cross-compiling on a
minimal build host, you spend almost half the time building things that
you don't even need. This trade-off will no longer be necessary as
BDEPEND will allow us to make that saving while avoiding the breakages
at the same time.

We do not expect all developers to be mindful of BDEPEND going
forwards. mgorny said that this could be thought of in the same way
that we currently don't beat developers up over mishandling of EPREFIX.
This will mean that I or others may occasionally swoop in to apply
BDEPEND to your packages and I hope that this isn't seen as rude or
invasive. It should have no effect on the non-cross case and for what
it's worth, I think I'm quite careful. :)

Also on the table is a variable called BROOT, which has arisen from bug
#509568. When calling executables from the build host, you can usually
rely on the PATH but sometimes the binary you need isn't in the PATH.
This obviously calls for an absolute path but what if the build host is
prefixed? EPREFIX always refers to the target host so how can you find
the prefix of the build host? Since the build host is always anchored
to / and we always refer to it absolutely, a BPREFIX variable is of
little use so we have therefore chosen BROOT. It's basically EROOT for
the build host.

Up to this point, I have referred to just the cross and non-cross cases
for simplicity. It may really be this simple but we should explore the
possibilities to make sure because I think one particular use case is a
little less clear cut.

--------

1. Regular native
   CHOST = CBUILD, PORTAGE_CONFIGROOT = /, ROOT = /

The traditional setup we're all familiar with. Everything goes to / so
the distinction between BDEPEND and DEPEND is irrelevant here.

2. Rooted native, same config
   CHOST = CBUILD, PORTAGE_CONFIGROOT = /, ROOT != /

This is almost exactly like #1 but the packages are not installed to /
at the end. Headers and libraries are still sourced from / and as such,
BDEPEND still doesn't apply. Despite an identical Portage configuration,
unexpected problems can arise. I did an experiment while writing this
and confirmed that having older libraries installed in / can lead to
breakages.

For example, say you have ncurses:0/5 installed in / and then attempt
to install i7z in a brand new ROOT. It will install ncurses:0/6 to ROOT
but then link the new i7z against libncurses.so.5. Furthermore, Portage
will record it as having been built against 0/6.

I think the easiest way to avoid problems like this is to ensure your
build host is up to date before you start installing things to ROOT.
Portage doesn't check this for you. Maybe it should?

3. Cross
   CHOST != CBUILD, PORTAGE_CONFIGROOT != /, ROOT != /

For all its difficulties, the theory is quite simple. You build using
ROOT as much as possible except when you need to execute something.
This includes headers, which must never be sourced from / as this
quickly leads to breakages. Ensuring this happens is probably easier
than you think. More on that later.

4. Rooted native, different config
   CHOST = CBUILD, PORTAGE_CONFIGROOT != /, ROOT != /

This is the messy one and one I'd like some feedback on as to what
people expect from it and whether it should even be supported at all.
Out of the box, it suffers from the same problems as #2 but keeping
your build host up to date is no longer sufficient. The target's USE
flags could potentially be entirely different, meaning that even the
same version of the same library could differ significantly between /
and ROOT. Even the headers could differ.

As far as I can see, the only sane way to deal with this is to build
against headers and libraries in ROOT instead, much like you would when
cross-compiling in #3. However, this just leaves you with the same
problem in reverse. Since you wouldn't really be cross-compiling, the
build may attempt to execute something that was just built. This
execution will occur in the context of the build host, which may not
have the necessary libraries available.

Perhaps you could force it to treat the build like a cross-compile by
overriding various checks in eclasses and build systems. This does
sound painful though. Another way would be to install an alternative
toolchain like x86_64-cross-linux-gnu. I know of one user who
successfully used this approach with cross-boss. It's probably not
bullet proof though as not all build systems respect CHOST and CBUILD.
I'm leaning towards the idea that this scenario should simply be
unsupported. You might as well start with a stage tarball and chroot
like usual. Do you have any better ideas?

It may seem like I have drifted off the point but I mention this use
case because we need to decide exactly when BDEPEND should apply. If
headers and libraries are sourced from ROOT then it needs to apply,
regardless of whether it is treated as a cross-compile or not.

--------

Still with me? ;)

I raised one further point with mgorny that he feels could potentially
go into EAPI 7 but I think could remain an implementation detail. In
cases #3 and #4 (basically when ROOT != / and PORTAGE_CONFIGROOT != /),
the toolchain needs to know how to source headers and libraries from
ROOT instead of /.

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.

In cross-boss, this argument is injected through some wrappers present
in the PATH, in a similar manner to distcc wrappers. This is remarkably
effective but doesn't quite cover everything.

CMake supports a CMAKE_SYSROOT argument that you set in the toolchain
file. We currently don't set this but it could easily be added to
cmake-utils.eclass as well as (or instead of?) the similar variables
that we already do set.

The vast majority of configure scripts (using libtool and not ancient)
support a --with-sysroot argument that can easily be detected by
grepping for lt_sysroot. The behaviour of econf is largely defined by
PMS, hence why mgorny thinks this particular detail could go into
EAPI 7, but it only says which arguments must be passed and doesn't say
that the PM can't pass additional ones. I don't wish this force this
stuff upon Paludis and pkgcore unnecessarily.

There's also a further complication here that I forgot to mention to
mgorny. While calling configure with --with-sysroot certainly helps,
it still stumbles on a significant number of packages that do
relinking at the end of the build if elibtoolize hasn't been called.
elibtoolize has long patched ltmain.sh with ELT-patches/cross/link-ROOT
when cross-compiling and this still applies to the very latest libtool.
I filed several bugs about this before realising that fixing this
globally would be better. elibtoolize doesn't require anything to be
installed and the description does say "this function should always be
safe to run" but I suppose calling it unconditionally might screw up
patching in some isolated cases. What do you think?

Phew, I'm done. Please be gentle! :)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

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

[Alexis Ballier]

Wow, what a lengthy email :)

On Tue, 1 Dec 2015 22:58:55 +0000
James Le Cuirot <chewi@gentoo.org> wrote:
[...]
> 
> I raised one further point with mgorny that he feels could potentially
> go into EAPI 7 but I think could remain an implementation detail. In
> cases #3 and #4 (basically when ROOT != / and
> PORTAGE_CONFIGROOT != /), the toolchain needs to know how to source
> headers and libraries from ROOT instead of /.

Use SYSROOT. ROOT has nothing to do with building. This should be
defined in PMS though.


> 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)

[...]
> CMake supports a CMAKE_SYSROOT argument that you set in the toolchain
> file. We currently don't set this but it could easily be added to
> cmake-utils.eclass as well as (or instead of?) the similar variables
> that we already do set.

iirc, CMAKE_SYSROOT is only for your case #4 and behaves more like
'build as if I had chrooted in CMAKE_SYSROOT' and thus doesn't help at
all for cross-compilation

> The vast majority of configure scripts (using libtool and not ancient)
> support a --with-sysroot argument that can easily be detected by
> grepping for lt_sysroot. The behaviour of econf is largely defined by
> PMS, hence why mgorny thinks this particular detail could go into
> EAPI 7, but it only says which arguments must be passed and doesn't
> say that the PM can't pass additional ones. I don't wish this force
> this stuff upon Paludis and pkgcore unnecessarily.


This could help your case #4. Or, e.g., stage building:
https://bugs.gentoo.org/show_bug.cgi?id=563034

toolchain's sysroot seems way more reliable though

[...]

Alexis.

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 4440 bytes --]

On Wed, 2 Dec 2015 12:40:08 +0100
Alexis Ballier <aballier@gentoo.org> wrote:

> On Tue, 1 Dec 2015 22:58:55 +0000
> James Le Cuirot <chewi@gentoo.org> wrote:
> [...]
> > 
> > I raised one further point with mgorny that he feels could
> > potentially go into EAPI 7 but I think could remain an
> > implementation detail. In cases #3 and #4 (basically when ROOT != /
> > and PORTAGE_CONFIGROOT != /), the toolchain needs to know how to
> > source headers and libraries from ROOT instead of /.
> 
> Use SYSROOT. ROOT has nothing to do with building. This should be
> defined in PMS though.

In case #2, ROOT != / but SYSROOT = / so I take your point that SYSROOT
would negate the need to check which use case we're dealing with.

I looked into SYSROOT while I was writing cross-boss. It's used in some
crossdev scripts, most notably cross-pkg-config, but not by pkg-config
itself. It's also used in a small handful of eclasses and other *-config
scripts but that's all. Conversely, the aforementioned libtool patch
uses ROOT and I suspect many other things do too. In practise, you need
to set both.

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.

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.

> > 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 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.

To be honest, these points are only an issue for #4, which is a use
case that I don't particularly care about. I only mentioned it because
I wanted to know if others were interested and what they expected from
it. Both problems can be worked around with an "x86_64-cross-linux-gnu"
toolchain, which is probably the only sane way to do this anyway for
the reasons I mentioned in the previous mail.

> [...]
> > CMake supports a CMAKE_SYSROOT argument that you set in the
> > toolchain file. We currently don't set this but it could easily be
> > added to cmake-utils.eclass as well as (or instead of?) the similar
> > variables that we already do set.
> 
> iirc, CMAKE_SYSROOT is only for your case #4 and behaves more like
> 'build as if I had chrooted in CMAKE_SYSROOT' and thus doesn't help at
> all for cross-compilation

Even without CMAKE_SYSROOT, since fixing the toolchain file stuff in
cmake-utils.eclass a little while back, CMake has actually been doing a
very good job of cross-compiling anyway. I doubt setting this would
make it any worse.

> This could help your case #4. Or, e.g., stage building:
> https://bugs.gentoo.org/show_bug.cgi?id=563034

I touched on these issues, including the subslot problem, in my
previous mail but it's good to know I'm not the only one who noticed.
This is really case #2 though. drobbins is using the same Portage
configuration so ensuring / is up to date should be sufficient. You
don't want to muddy that use case with the more tricky aspects of #4.

> toolchain's sysroot seems way more reliable though

As I said above, it only gets you so far. Trust me, I've seen enough
autotools failures to know. :)

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

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

[Alexis Ballier]

On Wed, 2 Dec 2015 23:20:05 +0000
James Le Cuirot <chewi@gentoo.org> wrote:

> On Wed, 2 Dec 2015 12:40:08 +0100
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Tue, 1 Dec 2015 22:58:55 +0000
> > James Le Cuirot <chewi@gentoo.org> wrote:
> > [...]  
> > > 
> > > I raised one further point with mgorny that he feels could
> > > potentially go into EAPI 7 but I think could remain an
> > > implementation detail. In cases #3 and #4 (basically when
> > > ROOT != / and PORTAGE_CONFIGROOT != /), the toolchain needs to
> > > know how to source headers and libraries from ROOT instead of /.  
> > 
> > Use SYSROOT. ROOT has nothing to do with building. This should be
> > defined in PMS though.  
> 
> In case #2, ROOT != / but SYSROOT = / so I take your point that
> SYSROOT would negate the need to check which use case we're dealing
> with.
> 
> I looked into SYSROOT while I was writing cross-boss. It's used in
> some crossdev scripts, most notably cross-pkg-config, but not by
> pkg-config itself. It's also used in a small handful of eclasses and
> other *-config scripts but that's all. Conversely, the aforementioned
> libtool patch uses ROOT and I suspect many other things do too. In
> practise, you need to set both.

The libtool patch has probably not been updated after SYSROOT
introduction. Feel free to file a bug about it.

> 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.
>
> 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.

And PMS is absolutely right.

Put simple:
SYSROOT is where "sources" are installed (headers, .so, etc); think
debian's -dev packages.
ROOT is where packages are merged.

Meaning:

RDEPEND are installed to ROOT
DEPEND are installed to SYSROOT
(BDEPEND are installed to /)

This implies that there is no guarantee at all that $ROOT is not
completely empty when executing any src_* phase since RDEPEND does not
need to be satisfied at that point.


(this also implies that for BDEPEND to make sense, you also need a
proper definition of SYSROOT in PMS)


[...]
> > [...]  
> > > CMake supports a CMAKE_SYSROOT argument that you set in the
> > > toolchain file. We currently don't set this but it could easily be
> > > added to cmake-utils.eclass as well as (or instead of?) the
> > > similar variables that we already do set.  
> > 
> > iirc, CMAKE_SYSROOT is only for your case #4 and behaves more like
> > 'build as if I had chrooted in CMAKE_SYSROOT' and thus doesn't help
> > at all for cross-compilation  
> 
> Even without CMAKE_SYSROOT, since fixing the toolchain file stuff in
> cmake-utils.eclass a little while back, CMake has actually been doing
> a very good job of cross-compiling anyway. I doubt setting this would
> make it any worse.

Try it. My memories definitely tell otherwise.

[...]

Alexis.

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

[Joakim Tjernlund]

On Thu, 2015-12-03 at 09:28 +0100, Alexis Ballier wrote:
> On Wed, 2 Dec 2015 23:20:05 +0000
> James Le Cuirot <chewi@gentoo.org> wrote:
> 
> > On Wed, 2 Dec 2015 12:40:08 +0100
> > Alexis Ballier <aballier@gentoo.org> wrote:
> > 
> > > On Tue, 1 Dec 2015 22:58:55 +0000
> > > James Le Cuirot <chewi@gentoo.org> wrote:
> > > [...]  
> > > > 
> > > > I raised one further point with mgorny that he feels could
> > > > potentially go into EAPI 7 but I think could remain an
> > > > implementation detail. In cases #3 and #4 (basically when
> > > > ROOT != / and PORTAGE_CONFIGROOT != /), the toolchain needs to
> > > > know how to source headers and libraries from ROOT instead of /.  
> > > 
> > > Use SYSROOT. ROOT has nothing to do with building. This should be
> > > defined in PMS though.  
> > 
> > In case #2, ROOT != / but SYSROOT = / so I take your point that
> > SYSROOT would negate the need to check which use case we're dealing
> > with.
> > 
> > I looked into SYSROOT while I was writing cross-boss. It's used in
> > some crossdev scripts, most notably cross-pkg-config, but not by
> > pkg-config itself. It's also used in a small handful of eclasses and
> > other *-config scripts but that's all. Conversely, the aforementioned
> > libtool patch uses ROOT and I suspect many other things do too. In
> > practise, you need to set both.
> 
> The libtool patch has probably not been updated after SYSROOT
> introduction. Feel free to file a bug about it.
> 
> > 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.
> > 
> > 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.
> 
> And PMS is absolutely right.
> 
> Put simple:
> SYSROOT is where "sources" are installed (headers, .so, etc); think
> debian's -dev packages.
> ROOT is where packages are merged.
> 
> Meaning:
> 
> RDEPEND are installed to ROOT
> DEPEND are installed to SYSROOT

hmm, this implies that a pkg in both DEPEND and RDEPEND should be installed in both
SYSROOT and ROOT? Does portage do this ATM?


> (BDEPEND are installed to /)

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Sun, 6 Dec 2015 21:05:07 +0000
Joakim Tjernlund <Joakim.Tjernlund@infinera.com> wrote:

> > Put simple:
> > SYSROOT is where "sources" are installed (headers, .so, etc); think
> > debian's -dev packages.
> > ROOT is where packages are merged.
> > 
> > Meaning:
> > 
> > RDEPEND are installed to ROOT
> > DEPEND are installed to SYSROOT  
> 
> hmm, this implies that a pkg in both DEPEND and RDEPEND should be
> installed in both SYSROOT and ROOT? Does portage do this ATM?

That's not quite how I read it. SYSROOT == ROOT when cross-compiling so
under EAPI 7, this would be true. In case #2, when not cross-compiling,
SYSROOT = / but ROOT would be something else. DEPEND would go to / and
RDEPEND would go to ROOT.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

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

[Alexis Ballier]

On Sun, 6 Dec 2015 21:15:31 +0000
James Le Cuirot <chewi@gentoo.org> wrote:

> On Sun, 6 Dec 2015 21:05:07 +0000
> Joakim Tjernlund <Joakim.Tjernlund@infinera.com> wrote:
> 
> > > Put simple:
> > > SYSROOT is where "sources" are installed (headers, .so, etc);
> > > think debian's -dev packages.
> > > ROOT is where packages are merged.
> > > 
> > > Meaning:
> > > 
> > > RDEPEND are installed to ROOT
> > > DEPEND are installed to SYSROOT    
> > 
> > hmm, this implies that a pkg in both DEPEND and RDEPEND should be
> > installed in both SYSROOT and ROOT? Does portage do this ATM?  
> 
> That's not quite how I read it. SYSROOT == ROOT when cross-compiling

while generally this would be the case, there's not reason for it to be
assumed. it is just like generally we have ROOT=/.

[...]

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

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2514 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Joakim Tjernlund]

On Tue, 2015-12-01 at 22:58 +0000, James Le Cuirot wrote:
> 

[SNIP really good writeup, thanks :)]

> There's also a further complication here that I forgot to mention to
> mgorny. While calling configure with --with-sysroot certainly helps,
> it still stumbles on a significant number of packages that do
> relinking at the end of the build if elibtoolize hasn't been called.
> elibtoolize has long patched ltmain.sh with ELT-patches/cross/link-ROOT

I looked at ELT-patches/cross/link-ROOT and it has
--- libltdl/config/ltmain.sh	2008-09-07 19:56:33.000000000 +0200
+++ libltdl/config/ltmain.sh.new	2009-02-15 20:37:47.000000000 +0100
@@ -5768,7 +5768,7 @@
 	       test "$hardcode_direct_absolute" = no; then
 	      add="$libdir/$linklib"
 	    elif test "$hardcode_minus_L" = yes; then
-	      add_dir="-L$libdir"
+	      add_dir="-L$ROOT/$libdir"
 	      add="-l$name"
 	    elif test "$hardcode_shlibpath_var" = yes; then
 	      case :$finalize_shlibpath: in
@@ -5785,7 +5785,7 @@
 	      fi
 	    else
 	      # We cannot seem to hardcode it, guess we'll fake it.
-	      add_dir="-L$libdir"
+	      add_dir="-L$ROOT/$libdir"

I think this should be "add_dir=-L$lt_sysroot$libdir" rather than ROOT.
See also bug https://bugs.gentoo.org/show_bug.cgi?id=521184
and since I think this is also a libool bug there is a post upstream
 http://lists.gnu.org/archive/html/libtool/2015-10/msg00012.html
This has not gotten any attention from upstream libtool folks. Would
be great if someone more could push for such a change.

 Jocke

> when cross-compiling and this still applies to the very latest libtool.
> I filed several bugs about this before realising that fixing this
> globally would be better. elibtoolize doesn't require anything to be
> installed and the description does say "this function should always be
> safe to run" but I suppose calling it unconditionally might screw up
> patching in some isolated cases. What do you think?
> 
> Phew, I'm done. Please be gentle! :)
> 

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

[James Le Cuirot]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

On Thu, 3 Dec 2015 08:22:01 +0000
Joakim Tjernlund <Joakim.Tjernlund@infinera.com> wrote:

> > There's also a further complication here that I forgot to mention to
> > mgorny. While calling configure with --with-sysroot certainly helps,
> > it still stumbles on a significant number of packages that do
> > relinking at the end of the build if elibtoolize hasn't been called.
> > elibtoolize has long patched ltmain.sh with
> > ELT-patches/cross/link-ROOT  
> 
> I looked at ELT-patches/cross/link-ROOT and it has
> --- libltdl/config/ltmain.sh	2008-09-07 19:56:33.000000000
> +0200 +++ libltdl/config/ltmain.sh.new	2009-02-15
> 20:37:47.000000000 +0100 @@ -5768,7 +5768,7 @@
>  	       test "$hardcode_direct_absolute" = no; then
>  	      add="$libdir/$linklib"
>  	    elif test "$hardcode_minus_L" = yes; then
> -	      add_dir="-L$libdir"
> +	      add_dir="-L$ROOT/$libdir"
>  	      add="-l$name"
>  	    elif test "$hardcode_shlibpath_var" = yes; then
>  	      case :$finalize_shlibpath: in
> @@ -5785,7 +5785,7 @@
>  	      fi
>  	    else
>  	      # We cannot seem to hardcode it, guess we'll fake it.
> -	      add_dir="-L$libdir"
> +	      add_dir="-L$ROOT/$libdir"
> 
> I think this should be "add_dir=-L$lt_sysroot$libdir" rather than
> ROOT. See also bug https://bugs.gentoo.org/show_bug.cgi?id=521184
> and since I think this is also a libool bug there is a post upstream
>  http://lists.gnu.org/archive/html/libtool/2015-10/msg00012.html
> This has not gotten any attention from upstream libtool folks. Would
> be great if someone more could push for such a change.

Agreed. I already wondered if there was an autotools variable that
would be more appreciate. Since aballier also said that this should be
corrected, I'll see about doing that in conjunction with these changes.

I wouldn't hold your breath for upstream. I've heard of them ignoring
other issues like the "as-needed" one for years.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

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

[Joakim Tjernlund]

On Thu, 2015-12-03 at 23:32 +0000, James Le Cuirot wrote:
> On Thu, 3 Dec 2015 08:22:01 +0000
> Joakim Tjernlund <Joakim.Tjernlund@infinera.com> wrote:
> 
> > > There's also a further complication here that I forgot to mention to
> > > mgorny. While calling configure with --with-sysroot certainly helps,
> > > it still stumbles on a significant number of packages that do
> > > relinking at the end of the build if elibtoolize hasn't been called.
> > > elibtoolize has long patched ltmain.sh with
> > > ELT-patches/cross/link-ROOT  
> > 
> > I looked at ELT-patches/cross/link-ROOT and it has
> > --- libltdl/config/ltmain.sh	2008-09-07 19:56:33.000000000
> > +0200 +++ libltdl/config/ltmain.sh.new	2009-02-15
> > 20:37:47.000000000 +0100 @@ -5768,7 +5768,7 @@
> >  	       test "$hardcode_direct_absolute" = no; then
> >  	      add="$libdir/$linklib"
> >  	    elif test "$hardcode_minus_L" = yes; then
> > -	      add_dir="-L$libdir"
> > +	      add_dir="-L$ROOT/$libdir"
> >  	      add="-l$name"
> >  	    elif test "$hardcode_shlibpath_var" = yes; then
> >  	      case :$finalize_shlibpath: in
> > @@ -5785,7 +5785,7 @@
> >  	      fi
> >  	    else
> >  	      # We cannot seem to hardcode it, guess we'll fake it.
> > -	      add_dir="-L$libdir"
> > +	      add_dir="-L$ROOT/$libdir"
> > 
> > I think this should be "add_dir=-L$lt_sysroot$libdir" rather than
> > ROOT. See also bug https://bugs.gentoo.org/show_bug.cgi?id=521184
> > and since I think this is also a libool bug there is a post upstream
> >  http://lists.gnu.org/archive/html/libtool/2015-10/msg00012.html
> > This has not gotten any attention from upstream libtool folks. Would
> > be great if someone more could push for such a change.
> 
> Agreed. I already wondered if there was an autotools variable that
> would be more appreciate. Since aballier also said that this should be
> corrected, I'll see about doing that in conjunction with these changes.
> 
> I wouldn't hold your breath for upstream. I've heard of them ignoring
> other issues like the "as-needed" one for years.

Upstream seems a bit unfocused and probably needs some prodding to get
going. The suggested change is simple and won't affect normal libtool use
so it should not be to hard to get it committed.

 Jocke, off for the weekend as of now.

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

[Guilherme Amadio]

On Tue, Dec 01, 2015 at 10:58:55PM +0000, James Le Cuirot wrote:
> Sorry for the length of this but you really need to consider the bigger
> picture with this stuff and not all devs are familiar with it.
> 
> For EAPI 7, mgorny and I are seeking to address some cross-compiling
> issues. This is a subject I've long had an interest in and before I
> became a developer, I created a project called cross-boss that, to be
> blunt, hacks its way through the shortcomings in Portage and the tree.
> It does (or at least did when I last worked on it) achieve a higher
> success rate than you would get from crossdev alone and allows you to
> install a brand new standalone system from scratch as opposed to one
> under /usr/${CHOST}.
> 
> I have heard some developers say that cross-compiling is simply not
> worth the effort but I have succeeded in building some big ticket items
> including MariaDB, GTK+, Qt4, and LibreOffice. This is one area where
> Gentoo can really shine so I would like to exploit that potential.

Thanks for the nice write up.

I've been using a prefix installation (no root privileges to use Gentoo)
and Intel compilers with Portage to cross compile stuff for the Xeon Phi[1].
For the most part I've just hacked my way into making things work, but
it would be cool to get a project going to do this properly.

Cheers,
—Guilherme

[1] https://software.intel.com/en-us/mic-developer

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

[Gregory M. Turner]

On Tue, 2015-12-01 at 22:58 +0000, James Le Cuirot wrote:
> Sorry
[snip]
>  gentle! :)

Not sure I have anything meaningful to contribute to the discussion
from a technical perspective at the moment, but I just wanted to voice
my support for what you're doing with cross: I think Gentoo is setting
some kind of standard -- or at least exerting a huge influence -- on
the worldwide group-think about what is possible and/or reasonable to
expect in cross-buildling frameworks and environments.

Unfortunately, the "standard" we are setting could clearly be higher.

Part of that comes down to a lack of manpower and testing at
the package level, which is not an easy problem to solve, as it
arises from the fundamentals of the market for open-source hacking
labor.

But what could be solved more readily is that the framework we have
today conflates some entities and concepts which are unified when
building locally, but divergent when cross-building.

Unravelling those conflations should help everyone  to experience less
cognitive dissonance and/or head-scratching-befuddlement, which, in
turn, could lead to a more productive, fun and easy-to-use cross-
building experience for users and developers alike, without expecting
any mysterious motivational forces to materialize from nowhere to
rescue us from the desire to watch TV or go on dates.

Anyhow, I say it's easier, but I know it's still pretty damn hard.  So,
thanks for working on this!

-gmt