svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Mark Millard]

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