Date: Sat, 15 Apr 2017 09:30:49 +1000 (AEST) From: Gerald Pfeifer <gerald@pfeifer.com> To: Pedro Giffuni <pfg@FreeBSD.org>, freebsd.contact@marino.st Cc: Mark Millard <markmi@dsl-only.net>, freebsd-ports@freebsd.org, freebsd-toolchain@freebsd.org, freebsd-arm@freebsd.org, freebsd-head@freebsd.org, ericturgeon.bsd@gmail.com Subject: Re: lang/gcc6-aux for head beyond __nonnull related issues: vm_ooffset_t and vm_pindex_t related changes (and more) Message-ID: <alpine.LNX.2.21.1704150928320.4604@anthias.pfeifer.com> In-Reply-To: <E86AC2D1-EE2D-4E33-85FD-8069B050421F@FreeBSD.org> References: <E54E495A-E4C8-40B3-B1E8-133A9872B6B2@dsl-only.net> <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> <E86AC2D1-EE2D-4E33-85FD-8069B050421F@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 13 Apr 2017, Pedro Giffuni wrote: > I didn’t 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 “fix” 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. Indeed, thanks for the analysis/background, Pedro! I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6, and perhaps John (as the maintainer of that port) has plans to update it? Let me copy him. Gerald PS: John, if you have an update, happy to help and apply that for you. From owner-freebsd-arm@freebsd.org Sat Apr 15 02:53:49 2017 Return-Path: <owner-freebsd-arm@freebsd.org> Delivered-To: freebsd-arm@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 07C78D3E1D6 for <freebsd-arm@mailman.ysv.freebsd.org>; Sat, 15 Apr 2017 02:53:49 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-41.reflexion.net [208.70.210.41]) (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 C1FD110D9 for <freebsd-arm@freebsd.org>; Sat, 15 Apr 2017 02:53:48 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1088 invoked from network); 15 Apr 2017 02:53:46 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 15 Apr 2017 02:53:46 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.0) with SMTP; Fri, 14 Apr 2017 22:53:46 -0400 (EDT) Received: (qmail 24506 invoked from network); 15 Apr 2017 02:53:46 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 15 Apr 2017 02:53:46 -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 5D889EC78CC; Fri, 14 Apr 2017 19:53:45 -0700 (PDT) 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: Mark Millard <markmi@dsl-only.net> In-Reply-To: <alpine.LNX.2.21.1704150928320.4604@anthias.pfeifer.com> Date: Fri, 14 Apr 2017 19:53:44 -0700 Cc: Pedro Giffuni <pfg@FreeBSD.org>, FreeBSD Ports <freebsd-ports@freebsd.org>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org>, ericturgeon.bsd@gmail.com, FreeBSD Current <freebsd-current@freebsd.org> Content-Transfer-Encoding: quoted-printable Message-Id: <FA9D3BB0-E5DA-4DAE-BA61-01BFCFBCC24C@dsl-only.net> References: <E54E495A-E4C8-40B3-B1E8-133A9872B6B2@dsl-only.net> <9758023E-1526-41F9-9416-6AC8AD3201B5@dsl-only.net> <E86AC2D1-EE2D-4E33-85FD-8069B050421F@FreeBSD.org> <alpine.LNX.2.21.1704150928320.4604@anthias.pfeifer.com> To: Gerald Pfeifer <gerald@pfeifer.com> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>; List-Post: <mailto:freebsd-arm@freebsd.org> List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>, <mailto:freebsd-arm-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 15 Apr 2017 02:53:49 -0000 On 2017-Apr-14, at 4:30 PM, Gerald Pfeifer <gerald@pfeifer.com> wrote: > On Thu, 13 Apr 2017, Pedro Giffuni wrote: >> 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. >>=20 >> 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. >=20 > Indeed, thanks for the analysis/background, Pedro! >=20 > I had a look at gcc6-aux is based on the 20170202 snapshot of GCC 6,=20= > and perhaps John (as the maintainer of that port) has plans to update=20= > it? Let me copy him. [As I have a prior E-mail exchange with John M. indicating that he was not intending to be the lang/gcc6-aux maintainer, I avoid spamming him with this material: I've removed him from the CC list in this reply. I can send the material to him if I see evidence of his wanting it.] Just FYI: [Previously: temporarily adding __nonnull and __nonnull_all back into into my local head FreeBSD variant got problems with: __vm_ooffset_t and __vm_pindex_t no longer existing and also the same pid_t issue indicated below.] I tried using [on a Pine64+ 2GB aarch64 system]: # = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap/libexec/gcc/aarc= h64-aux-freebsd12.0/6.3.1/install-tools/mkheaders = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/bootstrap to deal with __nonnull, __nonnull_all, __vm_ooffset_t, and = __vm_pindex_t. I then built via portmaster -CDK usage. Various header issues did go away but the build of lang/gcc6-aux still stopped with: In file included from = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:20:0: ./config.h:556:15: error: two or more data types in declaration = specifiers #define pid_t int ^ I'm guessing that the define for pid_t in config.h resulted in something like: typedef ??? pid_t; that turned into something like a: typedef ??? int; for the error listed above. There were also implicit-declaration warnings: = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c: In function 'simple_object_internal_read': = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:75:21: warning: implicit declaration of function 'read' = [-Wimplicit-function-declaration] ssize_t got =3D read (descriptor, buffer, size); ^~~~ = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c: In function 'simple_object_internal_write': = /usr/obj/portswork/usr/ports/lang/gcc6-aux/work/gcc-6-20170202/libiberty/s= imple-object.c:119:23: warning: implicit declaration of function 'write' = [-Wimplicit-function-declaration] ssize_t wrote =3D write (descriptor, buffer, size); ^~~~~ The implicit-declaration warnings for read and write may well also not be expected/desirable. It may be that more than a script run is needed to make things be appropriate. =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?alpine.LNX.2.21.1704150928320.4604>