Open xniine opened 7 years ago
That's a bit weird, considering that there's a --sysroot
there already. Might be worthwhile to consulting the docs or ask the gcc list if ignoring --sysroot
is an intended change in gcc 6.
With your proposed change, does everything work as expected (including being able to compile and run C++ programs from rumprun-packages)?
I tried on complie + reumprun-bake/rumprun, but not full test, so far it seems ok.
Also I did some check on the failed g++ command again
Some how in my environment, the /usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/include
and <sysroot>/usr/include
are both included.
I guess:
This one from gcc /usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/include
takes more precedence than <sysroot>/usr/include
and shadows the <sysroot>/usr/include/stdlib.h
.
The include sequence becomes /var/tmp/rumprun/obj-amd64-hw/rumptools/dest/usr/include/c++
then <some system path>
then /var/tmp/rumprun/obj-amd64-hw/rumptools/dest/usr/include
. Which caused this issue.
#include "..." search starts here:
#include <...> search starts here:
/var/tmp/rumprun/./obj-amd64-hw/include
/var/tmp/rumprun/src-netbsd/sys/lib/libunwind
/var/tmp/rumprun/obj-amd64-hw/rumptools/dest/usr/include/c++
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../include/c++/6.2.1
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../include/c++/6.2.1/x86_64-pc-linux-gnu
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/../../../../include/c++/6.2.1/backward
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/include
/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/include-fixed
/var/tmp/rumprun/obj-amd64-hw/rumptools/dest/usr/include
End of search list.
GNU C++11 (GCC) version 6.2.1 20160830 (x86_64-pc-linux-gnu)
compiled by GNU C version 6.2.1 20160830, GMP version 6.1.1, MPFR version 3.1.4-p1, MPC version 1.0.3, isl version 0.15
warning: MPFR header version 3.1.4-p1 differs from library version 3.1.5.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bfb50e0547e830f092456a1b04cf4850
In file included from /usr/include/c++/6.2.1/stdlib.h:36:0,
from /var/tmp/rumprun/src-netbsd/sys/lib/libunwind/UnwindCursor.hpp:16,
from /var/tmp/rumprun/src-netbsd/sys/lib/libunwind/libunwind.cxx:18:
/var/tmp/rumprun/obj-amd64-hw/dest.stage/include/c++/cstdlib:98:9: error: ‘::div_t’ has not been declared
using ::div_t;
^~~~~
/var/tmp/rumprun/obj-amd64-hw/dest.stage/include/c++/cstdlib:99:9: error: ‘::ldiv_t’ has not been declared
using ::ldiv_t;
^~~~~~
/var/tmp/rumprun/obj-amd64-hw/dest.stage/include/c++/cstdlib:101:9: error: ‘::lldiv_t’ has not been declared
using ::lldiv_t;
^~~~~~~
/var/tmp/rumprun/obj-amd64-hw/dest.stage/include/c++/cstdlib:103:9: error: ‘::atof’ has not been declared
using ::atof;
^~~~
Ah, so the new thing with gcc 6.2.1 is probably that it ships with stdlib.h
.
Bah, the sysroot stuff is really horrible, because apparently it's really no longer a sysroot at all.
Anyway, I think your patch is ok. Please submit a pull request for it. Also, I encourage you to submit the shift-negative-value problem upstream to llvm/libunwind.
Failed on gcc 4.8.4 with this -Wno-error=shift-negative-value
. I think I need a better fix.
Currently, the canonical way to deal with compiler flag differences is to test for them in buildrump.sh and add them to CCWRAPPER_MANGLE
if necessary.
oh, and add yourself to AUTHORS if you like. (yes, it's a "one-liner" fix, but as you've probably no doubt noticed, these "one-liners" for maintaining toolchain support take quite a bit of time, and can easily shadow implementing new features)
See also discussion in PR #87
The llvm/libunwind bug seems to be fixed now, what needs to be done to use the fixed version?
The fix is also now merged into NetBSD HEAD. I'm guessing rumpkernel/netbsd-src would need to be bumped on the next release?
Hi, I recently hit a compile issue on gcc 6.2.1, put on the error message/walkround on myside.