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 :

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 

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.
> -- 
> Regards,
> Bryan Drewery

Mark Millard
markmi at dsl-only.net

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to