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. > 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? 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. 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. 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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:05 UTC