| 1 |
On Wed, 2 Dec 2015 12:40:08 +0100 |
| 2 |
Alexis Ballier <aballier@g.o> wrote: |
| 3 |
|
| 4 |
> On Tue, 1 Dec 2015 22:58:55 +0000 |
| 5 |
> James Le Cuirot <chewi@g.o> wrote: |
| 6 |
> [...] |
| 7 |
> > |
| 8 |
> > I raised one further point with mgorny that he feels could |
| 9 |
> > potentially go into EAPI 7 but I think could remain an |
| 10 |
> > implementation detail. In cases #3 and #4 (basically when ROOT != / |
| 11 |
> > and PORTAGE_CONFIGROOT != /), the toolchain needs to know how to |
| 12 |
> > source headers and libraries from ROOT instead of /. |
| 13 |
> |
| 14 |
> Use SYSROOT. ROOT has nothing to do with building. This should be |
| 15 |
> defined in PMS though. |
| 16 |
|
| 17 |
In case #2, ROOT != / but SYSROOT = / so I take your point that SYSROOT |
| 18 |
would negate the need to check which use case we're dealing with. |
| 19 |
|
| 20 |
I looked into SYSROOT while I was writing cross-boss. It's used in some |
| 21 |
crossdev scripts, most notably cross-pkg-config, but not by pkg-config |
| 22 |
itself. It's also used in a small handful of eclasses and other *-config |
| 23 |
scripts but that's all. Conversely, the aforementioned libtool patch |
| 24 |
uses ROOT and I suspect many other things do too. In practise, you need |
| 25 |
to set both. |
| 26 |
|
| 27 |
On reflection, I'm now thinking that we should call it something less |
| 28 |
generic. I also found that the Qt build uses SYSROOT for its own |
| 29 |
purposes so you cannot rely on it in toolchain wrappers. ROOT is |
| 30 |
probably just as unreliable. For that reason, I ended up using |
| 31 |
CB_SYSROOT in cross-boss. |
| 32 |
|
| 33 |
I forgot to mention earlier that if ROOT were used, PMS actually |
| 34 |
forbids it from being referenced in the src_* phases so this |
| 35 |
restriction would need to be lifted. Relying on the toolchain's |
| 36 |
internal sysroot is not sufficient. |
| 37 |
|
| 38 |
> > gcc and friends support a --sysroot argument. It used to be the case |
| 39 |
> > that this didn't work on a toolchain configured without a sysroot, |
| 40 |
> > possibly creating issues for #4, but I've tested and it now works |
| 41 |
> > regardless. |
| 42 |
> |
| 43 |
> $ gcc --sysroot=/tmp/foo -I/usr/include foo.c |
| 44 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/5.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: |
| 45 |
> this linker was not configured to use sysroots |
| 46 |
> collect2: error: ld returned 1 exit status |
| 47 |
> |
| 48 |
> Two problems here: |
| 49 |
> 1. link fails |
| 50 |
> 2. gcc doesn't warn for -I/usr/include with sysroot (iirc crossdev's |
| 51 |
> gcc do) |
| 52 |
|
| 53 |
Yeah, turns out my hello.c test was not sufficient. It seems gcc is |
| 54 |
fine with it but binutils isn't. This seems silly to me so maybe this |
| 55 |
could be patched out or perhaps building the native binutils with |
| 56 |
--with-sysroot=/ would work? |
| 57 |
|
| 58 |
I know about -Wpoison-system-directories. We only enable it for |
| 59 |
cross-compilers but I think it only triggers when cross-compiling |
| 60 |
anyway. It's a shame they didn't make it dependent on --sysroot |
| 61 |
instead. |
| 62 |
|
| 63 |
To be honest, these points are only an issue for #4, which is a use |
| 64 |
case that I don't particularly care about. I only mentioned it because |
| 65 |
I wanted to know if others were interested and what they expected from |
| 66 |
it. Both problems can be worked around with an "x86_64-cross-linux-gnu" |
| 67 |
toolchain, which is probably the only sane way to do this anyway for |
| 68 |
the reasons I mentioned in the previous mail. |
| 69 |
|
| 70 |
> [...] |
| 71 |
> > CMake supports a CMAKE_SYSROOT argument that you set in the |
| 72 |
> > toolchain file. We currently don't set this but it could easily be |
| 73 |
> > added to cmake-utils.eclass as well as (or instead of?) the similar |
| 74 |
> > variables that we already do set. |
| 75 |
> |
| 76 |
> iirc, CMAKE_SYSROOT is only for your case #4 and behaves more like |
| 77 |
> 'build as if I had chrooted in CMAKE_SYSROOT' and thus doesn't help at |
| 78 |
> all for cross-compilation |
| 79 |
|
| 80 |
Even without CMAKE_SYSROOT, since fixing the toolchain file stuff in |
| 81 |
cmake-utils.eclass a little while back, CMake has actually been doing a |
| 82 |
very good job of cross-compiling anyway. I doubt setting this would |
| 83 |
make it any worse. |
| 84 |
|
| 85 |
> This could help your case #4. Or, e.g., stage building: |
| 86 |
> https://bugs.gentoo.org/show_bug.cgi?id=563034 |
| 87 |
|
| 88 |
I touched on these issues, including the subslot problem, in my |
| 89 |
previous mail but it's good to know I'm not the only one who noticed. |
| 90 |
This is really case #2 though. drobbins is using the same Portage |
| 91 |
configuration so ensuring / is up to date should be sufficient. You |
| 92 |
don't want to muddy that use case with the more tricky aspects of #4. |
| 93 |
|
| 94 |
> toolchain's sysroot seems way more reliable though |
| 95 |
|
| 96 |
As I said above, it only gets you so far. Trust me, I've seen enough |
| 97 |
autotools failures to know. :) |
| 98 |
|
| 99 |
-- |
| 100 |
James Le Cuirot (chewi) |
| 101 |
Gentoo Linux Developer |
Archives