From owner-freebsd-toolchain@freebsd.org Fri Apr 14 02:30:51 2017 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01ADED3D57F for ; Fri, 14 Apr 2017 02:30:51 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1.freebsd.org (Postfix) with SMTP id D3A13AEA for ; Fri, 14 Apr 2017 02:30:50 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: (qmail 83439 invoked by uid 99); 14 Apr 2017 02:30:49 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Apr 2017 02:30:49 +0000 Received: from [192.168.0.104] (unknown [190.157.139.67]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 0171A1A002E; Fri, 14 Apr 2017 02:30:47 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) From: Pedro Giffuni In-Reply-To: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> Date: Thu, 13 Apr 2017 21:32:14 -0500 Cc: Gerald Pfeifer , FreeBSD Ports , FreeBSD Toolchain , freebsd-arm , freebsd-head@freebsd.org, ericturgeon.bsd@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> To: Mark Millard X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 02:30:51 -0000 > On Apr 13, 2017, at 20:38, Mark Millard wrote: >=20 > [I accidentally sent the original of the "on . . . wrote" > below to the wrong toolchain list. This just corrects that.] >=20 > [I'll also note that lang/gcc6-aux was indirectly attempted > when I tried to build ports-mgmt/synth on a Pine64+ 2GB > (an aarch64 context). I had noticed the recent update claiming > native aarch64 support for synth and tried to build it. I've > no direct interest in lang/gcc6-aux . I just ended up with > FYI information about lang/gcc6-aux .] >=20 I didn=E2=80=99t want to get into this but the problem is that as part = of it's build/bootstrapping process, GCC historically takes system headers and attempts to =E2=80=9Cfix=E2=80=9D them. I am unsure the fixes do = anything at all nowadays but the effect is that the compiler tends to take snapshots of the system headers when it is built. cdefs.h is used by all the system headers so changes in cdefs.h have good chances affecting such builds but any change are likely to cause similar trouble. In the case of gcc-aux, it appears the compilation is based on a bootstrap compiler which already carries outdated headers. A workaround, suggested by gerald@ the last time a similar issue happened was to run for install-tools/fixinc.sh. I think that may regenerate the headers and let the build use updated headers. Ultimately gcc-aux needs maintainer intervention and using outdated headers will break sooner or later: especially on -current. Hope that helps, Pedro. > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > (I've added a missing "n" in the first "__nonnull_all" below.) > On 2017-Apr-13, at 6:04 PM, Mark Millard = wrote: >=20 >> As means of investigating if lang/gcc6-aux has other problems >> building on aarch64 than just __nonnull and __nonnull_all I did: >>=20 >> # svnlite diff /usr/src/sys/sys/ >> Index: /usr/src/sys/sys/cdefs.h >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> --- /usr/src/sys/sys/cdefs.h (revision 315914) >> +++ /usr/src/sys/sys/cdefs.h (working copy) >> @@ -376,6 +376,10 @@ >> #define __noinline >> #endif >>=20 >> +// HACK to enable older source that did not track. >> +#define __nonnull(x) >> +#define __nonnull_all >> + >> #if __GNUC_PREREQ__(3, 4) >> #define __fastcall __attribute__((__fastcall__)) >> #define __result_use_check = __attribute__((__warn_unused_result__)) >>=20 >> and so such similarly shows up in /usr/include/sys/cdefs.h . >>=20 >> The attempt to build lang/gcc6-aux (as part of attempting >> to build ports-mgmt/synth) resulted in: >>=20 >>=20 >> In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f= dmatch.c:45:0: >> ./config.h:556:15: error: two or more data types in declaration = specifiers >> #define pid_t int >> ^ >> In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/f= dmatch.c:49:0: >> = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:266:9: error: unknown = type name '__vm_ooffset_t' >> typedef __vm_ooffset_t vm_ooffset_t; >> ^~~~~~~~~~~~~~ >> = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:268:9: error: unknown = type name '__vm_pindex_t' >> typedef __vm_pindex_t vm_pindex_t; >> ^~~~~~~~~~~~~ >> gmake[4]: *** [Makefile:732: fdmatch.o] Error 1 >> gmake[4]: Leaving directory = '/usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty' >> gmake[3]: *** [Makefile:7458: all-libiberty] Error 2 >> gmake[3]: *** Waiting for unfinished jobs.... >>=20 >>=20 >> vm_ooffset_t and vm_pindex_t has 2017-Feb-4 changes: >>=20 >> Revision 313194 - (view) (download) (annotate) - [select for diffs]=20= >> Modified Sat Feb 4 12:26:38 2017 UTC (2 months, 1 week ago) by kib=20 >> File length: 10733 byte(s)=20 >> Diff to previous 299571 >> Define the vm_ooffset_t and vm_pindex_t types as machine-independend. >>=20 >> The types are for the byte offset and page index in vm object. They >> are similar to off_t, which is defined as 64bit MI integer. Using MI >> definitions will allow to provide consistent MD values of vm >> object-related maximum sizes. >>=20 >> Reviewed by: alc >> Sponsored by: The FreeBSD Foundation >> MFC after: 1 week >>=20 >>=20 >> The "#define pid_t int" in the local: >>=20 >> = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/build/libiberty/config.h >>=20 >> likely messes up some later "typedef . . . pid_t;", such as: >>=20 >> = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/lib/gcc/aarch64-= aux-freebsd12.0/6.3.1/include-fixed/sys/types.h:typedef __pid_t = pid_t; /* process id */ >>=20 >> resulting in: >>=20 >> typedef __pid_t int; >>=20 >>=20 >>=20 >> So lang/gcc6-aux bootstrapping has more problems than just __nonnull >> and __nonnull_all issues, at least for aarch64 head. >>=20 >> lang/gcc6-aux might not be the only thing with such issues. >>=20 >>=20 >> I stopped with this. There could be more issues for lang/gcc6-aux . >=20