On 2016-May-27, at 4:48 PM, Bryan Drewery <bdrewery at FreeBSD.org> wrote:
> On 3/31/2016 8:33 PM, Mark Millard wrote: >> I appears that C++ needs its own override for where to find C++ header >> before looking in the gcc49 specific places. > > Yes, the hacks for that are builtin already. Passing C_INCLUDE_PATH and > others may break it. When I try the experiment I'll try to remember to disable any such env based workarounds that I currently have in place. >> These sorts of odd, hard to avoid dependencies are part of why I asked if >> there was a standard/recommend assignment to use for CC/XCC: I was hoping >> there was a known-good way to compile that avoided the issues, possibly by >> using powerpc64-gcc tools for CC/XCC as well. > > You shouldn't need to pass any extra -I/-isystem or env vars for paths. > The problem in this thread was just the ports compiler using > /usr/local/include when not using a --sysroot. This is only in the > early phase of the build. > > Mind trying this patch? I'm currently doing libc++ related build experiments for Dimitry Andric. A successful build would end about 8 hours from now. So it will be a while before I can get to your experiment. > https://people.freebsd.org/~bdrewery/patches/gcc-no-local-include.patch > > I assume you are using that port, if not you can apply the same change > to whichever your ports gcc came from. For the powerpc64 context I use lang/gcc49 and devel/powerpc64-xtoolchain-gcc (so devel/powerpc64-gcc which is a 5.3 variant that has file conflicts with lang/gcc5's 5.3). I use lang/gcc49 instead of lang/gcc5 because of devel/powerpc64-gcc conflicting. No gcc 4.2.1 present or built. System clang built but unused. > It removes the /usr/local/include path. It is somewhat the wrong fix vs > "fixing the order", but the /usr/local/lib path is not in there now and > you must use -rpath with the ports gcc anyhow. So the ports gcc is > already broken for /usr/local, it should be fully broken or fully fixed, > not half broken to the point of breaking other things. + --with-local-prefix=/usr/include \ looks wrong to me. The default is not /usr/local/include but just /usr/local . Quoting https://gcc.gnu.org/install/configure.html : --with-local-prefix=dirname Specify the installation directory for local include files. The default is /usr/local. Specify this option if you want the compiler to search directory dirname/include for locally installed header files instead of /usr/local/include. So your change would generate /usr/include/include for the overall include path from what I can tell. Do you want: + --with-local-prefix=/usr \ instead? > I'm still just curious if it fixes the problems with "stage 3" finding > the wrong dwarf header, and if removing your own include path hacks > progresses the build further. > > -- > Regards, > Bryan Drewery === Mark Millard markmi at dsl-only.net _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
