svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)
markmi at dsl-only.net
Sat May 28 00:15:38 UTC 2016
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.
> 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 :
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 \
> 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.
> Bryan Drewery
markmi at dsl-only.net
More information about the freebsd-current