Date: Fri, 27 May 2016 17:15:30 -0700 From: Mark Millard <markmi@dsl-only.net> To: Bryan Drewery <bdrewery@FreeBSD.org> Cc: FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org>, Gerald Pfeifer <gerald@FreeBSD.org>, Warner Losh <imp@bsdimp.com> Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) Message-ID: <4953F764-FC4E-491F-A6B7-4CAF65EAAEB7@dsl-only.net> In-Reply-To: <db60bcec-a6c4-02ac-da6c-1ac70821b806@FreeBSD.org> References: <5A0ACA76-6F1D-4975-9E59-2A64BB8EFC77@dsl-only.net> <56FD9757.6040709@FreeBSD.org> <9E3033D5-F416-4B78-97C2-0A0AABF5A49E@dsl-only.net> <56FDA5F9.1090601@FreeBSD.org> <481DA341-0DFC-4AF1-AD4D-56C5388FA8E3@dsl-only.net> <56FDBAA8.5060407@FreeBSD.org> <7DEF97EC-D970-4F64-AF72-8939609A1D48@dsl-only.net> <DD969902-BCA8-480B-B32F-07DCC6C3E32B@dsl-only.net> <db60bcec-a6c4-02ac-da6c-1ac70821b806@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > 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. >=20 > 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. >=20 > 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 >=20 > 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=3D/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=3Ddirname 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=3D/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. >=20 > --=20 > Regards, > Bryan Drewery =3D=3D=3D Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4953F764-FC4E-491F-A6B7-4CAF65EAAEB7>