Date: Sat, 2 Apr 2016 23:06:48 -0700 From: Mark Millard <markmi@dsl-only.net> To: Warner Losh <imp@bsdimp.com>, Bryan Drewery <bdrewery@freebsd.org> Cc: Dimitry Andric <dim@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, Gerald Pfeifer <gerald@freebsd.org>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build) Message-ID: <53DAD70E-8DE4-4DBA-BF88-AD7F51B0B816@dsl-only.net> In-Reply-To: <D0AEEEEF-DE31-4A60-975E-2679758FFC59@dsl-only.net> 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> <DD2A166A-28D3-4F97-A084-6109B0BA21CC@bsdimp.com> <5FDFDC6A-911B-4A77-BCEF-BBB711BFA0AC@FreeBSD.org> <CANCZdfoa3kth8USvLXXrzAO5KgbizN29WCj4ebb02=Nj75ZU6A@mail.gmail.com> <5334F356-982F-40CA-9009-41B59AAC8665@dsl-only.net> <D0AEEEEF-DE31-4A60-975E-2679758FFC59@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Apr-2, at 3:59 PM, Mark Millard <markmi at dsl-only.net> wrote:
> [My testing for the likes of the below does not yet extend outside =
powerpc64 contexts.]
>=20
> For the likes of self-hosted powerpc64-xtoolchain-gcc/powerpc64-gcc =
use with, say, gcc49 materials as the so-called "host" compiler tools I =
have not yet found a way around using the workaround:
>=20
>> # ls -l /usr/lib/libstdc++.*
>> lrwxr-xr-x 1 root wheel 17 Feb 23 00:09 /usr/lib/libstdc++.a -> =
/usr/lib/libc++.a
>> lrwxr-xr-x 1 root wheel 18 Feb 23 00:09 /usr/lib/libstdc++.so -> =
/usr/lib/libc++.so
>=20
>=20
>=20
> But I appear to now have a src.conf (or a family of them) that avoids =
needing workarounds in /usr/local/include and /usr/local/lib for =
filename conflicts. This is based on CC/CXX ("HOST") and XCC/XCXX =
("CROSS") in src.conf being the likes of:
>=20
> "HOST" (CC/CXX):
>> CC=3Denv C_INCLUDE_PATH=3D/usr/include /usr/local/bin/gcc49 =
-L/usr/lib
>> CXX=3Denv C_INCLUDE_PATH=3D/usr/include =
CPLUS_INCLUDE_PATH=3D/usr/include/c++/v1 /usr/local/bin/g++49 -std=3Dc++11=
-nostdinc++ -L/usr/lib
>=20
> and. . .
>=20
> "CROSS" (XCC/XCXX):
>> TO_TYPE=3Dpowerpc64
>> TOOLS_TO_TYPE=3D${TO_TYPE}
>> . . .
>> VERSION_CONTEXT=3D11.0
>> . . .
>> =
XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-gc=
c
>> =
XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-portbld-freebsd${VERSION_CONTEXT}-g=
++
>=20
> In other words: CROSS use is already handled for /usr/local/. . . just =
given the compiler paths but some special src.conf adjustments beyond =
compiler paths were needed for HOST.
>=20
> So far it appears that gcc49 materials can be used in "CROSS" and/or =
powerpc64-gcc materials can be used in "HOST" via just appropriate =
compiler-path editing. (I have jumped to testing -r297514 but am still =
doing various build tests. So this aspect is subject to updates.) It =
appears to be possible to use just one compiler/tool family --but in the =
2 different ways-- instead of using a mix of 2 compiler/tool families.
>=20
> Historically I've not gotten gcc variants to make a working lib32 for =
powerpc64 and I've yet to retest this: So no claims about the lib32 =
status are implied here. (The problem was code in crtbeginS that =
arbitrarily used R30 in a way that the context was not set up for and so =
crtbeginS code was dereferencing arbitrary addresses.)
I probably knew this someplace in the back of my head but gcc49 does not =
handle -fformat-extensions (quoting the script log):
> --- accf_data.o ---
> env /usr/local/bin/gcc49 -isystem =
/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include =
-L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib =
--sysroot=3D/usr/obj/xtoolchain/powerpc.powerp
> c64/usr/src/tmp -B/usr/local/powerpc64-portbld-freebsd11.0/bin/ -O2 =
-pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc =
-DHAVE_KERNEL_OPTION_HEADERS -include =
/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG/op=
t_global.h -I. -I/usr/src/sys -fno-common -g -mlongcall =
-fno-omit-frame-pointer =
-I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODEBUG =
-MD -MF.depend.accf_data.o -MTaccf_data.o -mno-altivec -ffreestanding =
-fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls =
-Wnested-externs -Wstrict-prototypes -Wmissing-prototypes =
-Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign =
-fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option =
-Wno-unknown-pragmas -Wno-error=3Dinline -Wno-error=3Denum-compare =
-Wno-error=3Dunused-but-set-variable =
-Wno-error=3Daggressive-loop-optimizations =
-Wno-error=3Dmaybe-uninitialized -Wno-error=3Darray-bounds =
-Wno-error=3Daddress -Wno-error=3Dcast-qual -Wno-error=3Dsequence-point =
-Wno-error=3Dattributes -Wno-error=3Dstrict-overflow =
-Wno-error=3Doverflow -v -finline-limit=3D15000 -fms-extensions --param =
inline-unit-growth=3D100 --param large-function-growth=3D1000 =
-msoft-float -mcall-aixdesc -std=3Diso9899:1999 -c =
/usr/src/sys/modules/accf_data/../../netinet/accf_data.c -o accf_data.o
> Using built-in specs.
> COLLECT_GCC=3D/usr/local/bin/gcc49
> gcc49: error: unrecognized command line option '-fformat-extensions'
> Target: powerpc64-portbld-freebsd11.0
> Configured with: ./../gcc-4.9-20160210/configure --disable-multilib =
--disable-bootstrap --disable-nls --enable-gnu-indirect-function =
--libdir=3D/usr/local/lib/gcc49 --libexecdir=3D/usr/local/libexec/gcc49 =
--program-suffix=3D49 --with-as=3D/usr/local/bin/as =
--with-gmp=3D/usr/local =
--with-gxx-include-dir=3D/usr/local/lib/gcc49/include/c++/ =
--with-ld=3D/usr/local/bin/ld --with-pkgversion=3D'FreeBSD Ports =
Collection' --with-system-zlib --disable-libgcj =
--enable-languages=3Dc,c++,objc,fortran --prefix=3D/usr/local =
--localstatedir=3D/var --mandir=3D/usr/local/man =
--infodir=3D/usr/local/info/gcc49 --build=3Dpowerpc64-portbld-freebsd11.0
> Thread model: posix
> gcc version 4.9.4 20160210 (prerelease) (FreeBSD Ports Collection)=20
> *** [accf_data.o] Error code 1
So my
> it appears that gcc49 materials can be used in "CROSS"
is just false for gcc49, gcc5, and the like.
I had hoped such would work with TARGET_ARCH=3Dpowerpc because there is =
no powerpc-gcc port predefined and clang 3.8.0 is still insufficient for =
this context.
=3D=3D=3D
Mark Millard
markmi at dsl-only.net
On 2016-Apr-1, at 4:35 PM, Mark Millard <markmi at dsl-only.net> wrote:
>=20
> [Just a top-post showing what powerpc64-xtoolchain-gcc/powerpc64-gcc =
has for the default include search places:]
>=20
> powerpc64-xtoolchain-gcc/powerpc64-gcc also looks in =
/usr/local/include before /usr/include : see below.
>=20
>> # portmaster --list-origins
>> . . .
>> devel/powerpc64-xtoolchain-gcc
>> . . .
>>=20
>> # /usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --version
>> powerpc64-portbld-freebsd11.0-gcc (FreeBSD Ports Collection for =
powerpc64) 5.3.0
>> Copyright (C) 2015 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions. There =
is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR =
PURPOSE.
>>=20
>> # echo '' |/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc -v -x c++ =
- -o /dev/null
>> . . .
>> ignoring nonexistent directory =
"/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ=
e/c++/5.3.0"
>> ignoring nonexistent directory =
"/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ=
e/c++/5.3.0/powerpc64-portbld-freebsd11.0"
>> ignoring nonexistent directory =
"/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../includ=
e/c++/5.3.0/backward"
>> ignoring nonexistent directory =
"/usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/../../../../powerp=
c64-portbld-freebsd11.0/include"
>> #include "..." search starts here:
>> #include <...> search starts here:
>> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include
>> /usr/local/include
>> /usr/local/lib/gcc/powerpc64-portbld-freebsd11.0/5.3.0/include-fixed
>> /usr/include
>> End of search list.
>> . . .
>=20
>=20
> =3D=3D=3D
> Mark Millard
> markmi at dsl-only.net
> On 2016-Apr-1, at 7:25 AM, Warner Losh <imp at bsdimp.com> wrote:
>=20
>=20
>=20
> On Fri, Apr 1, 2016 at 2:25 AM, Dimitry Andric <dim@freebsd.org> =
wrote:
> On 01 Apr 2016, at 00:44, Warner Losh <imp@bsdimp.com> wrote:
>>=20
>>> On Mar 31, 2016, at 4:34 PM, Bryan Drewery <bdrewery@freebsd.org> =
wrote:
>>> I didn't realize the ports compiler was defaulting =
/usr/local/include
>>> into the search path now. It does not have /usr/local/lib in the
>>> default library path as far as I can tell. It's also broken for its
>>> -rpath (noted in its pkg-message). So having a default
>>> /usr/local/include path seems odd.
>>=20
>> It has for a while now. It=E2=80=99s one of the maddening =
inconsistencies that abound in this
>> area. I took a poll a while ago and there seemed to be widespread =
support for adding
>> it to the base compiler.
>=20
> This was the main reason /usr/local/include was *not* included in the
> base compiler, otherwise it would unpredictably pick up headers in
> /usr/local/include during builds. You can never know which =
conflicting
> headers a certain user has installed in /usr/local/include... :)
>=20
> That's why it shouldn't be *FIRST*, not why it shouldn't be there
> at all.
>=20
>>> Adding -isystem /usr/include to fix this is probably possible but
>>> there's a risk someone will remove it as redundant. In this case I =
wish
>>> /usr/include was first but I'm not sure what impact that would have =
on
>>> consumers expecting /usr/local/include (and /usr/local/lib) =
overrides to
>>> work, though they would need to pass a -L /usr/local/lib anyhow and
>>> would likely be passing -I /usr/local/lib too.
>>=20
>> /usr/include should be first. But it isn=E2=80=99t. That=E2=80=99s =
another inconsistency that was found
>> when we looked at /usr/local stuff. Someone recently added =
/usr/local/bin to the path,
>> if I recall correctly.
>=20
> Isn't that a bit of a bikeshed? I guess some people would just as =
well
> prefer /usr/local/include to be first, just like some people prefer
> /usr/local/bin before /usr/bin in their PATH.
>=20
> Sigh. No. /usr/local is moving into many different things in the base =
and ports. We should
> do it in a consistent way. What we have now is not consistent and =
somewhat brittle.
>=20
> In any case, if such paths are added to external compilers, we better
> make sure almost everything in buildworld uses -nostdinc, and =
specifying
> exactly the include directories we need, and no others. Cumbersome, =
but
> maybe for a good cause.
>=20
> That's the non-brittle solution here. An over-reliance on defaults =
makes it
> difficult to ensure other compilers will work, especially ones we =
don't
> tightly control the defaults for.
>=20
> Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53DAD70E-8DE4-4DBA-BF88-AD7F51B0B816>