On Wed, 2 Dec 2015 12:40:08 +0100 Alexis Ballier <aball...@gentoo.org> wrote:
> On Tue, 1 Dec 2015 22:58:55 +0000 > James Le Cuirot <ch...@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
pgpwLmdl04aGg.pgp
Description: OpenPGP digital signature
