From owner-freebsd-ports@freebsd.org Fri Apr 14 01:39:01 2017 Return-Path: Delivered-To: freebsd-ports@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 A3B12D3D77F for ; Fri, 14 Apr 2017 01:39:01 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-43.reflexion.net [208.70.210.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 63212E88 for ; Fri, 14 Apr 2017 01:39:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29027 invoked from network); 14 Apr 2017 01:40:00 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 14 Apr 2017 01:40:00 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Thu, 13 Apr 2017 21:38:59 -0400 (EDT) Received: (qmail 15639 invoked from network); 14 Apr 2017 01:38:59 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 14 Apr 2017 01:38:59 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7E3A5EC7901; Thu, 13 Apr 2017 18:38:58 -0700 (PDT) Content-Type: text/plain; charset=us-ascii 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: Mark Millard In-Reply-To: Date: Thu, 13 Apr 2017 18:38:57 -0700 Cc: freebsd-arm , freebsd-head@freebsd.org, ericturgeon.bsd@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> References: To: Gerald Pfeifer , Pedro Giffuni , FreeBSD Ports , FreeBSD Toolchain X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 01:39:01 -0000 [I accidentally sent the original of the "on . . . wrote" below to the wrong toolchain list. This just corrects that.] [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 .] =3D=3D=3D Mark Millard markmi at dsl-only.net (I've added a missing "n" in the first "__nonnull_all" below.) On 2017-Apr-13, at 6:04 PM, Mark Millard wrote: > 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 .