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
signature.asc
Description: Digital signature
